RE: Industry db benchmark result on recent 2.6 kernels

[Kevin Puetz]

Linus Torvalds wrote:

> 
> 
> On Fri, 1 Apr 2005, Chen, Kenneth W wrote:
>> 
>> Paul, you definitely want to check this out on your large numa box.  I
>> booted a kernel with this patch on a 32-way numa box and it took a long
>>  time to produce the cost matrix.
> 
> Is there anything fundamentally wrong with the notion of just initializing
> the cost matrix to something that isn't completely wrong at bootup, and
> just lettign user space fill it in?

Wouldn't getting rescheduled (and thus having another program trash the
cache on you) really mess up the data collection though? I suppose by
spawning off threads, each with a fixed affinity and SCHED_FIFO one could
hang onto the CPU to collect the data. But then it's not (a lot) different
than doing it in-kernel.
 
> Then you couple that with a program that can do so automatically (ie
> move the in-kernel heuristics into user-land), and something that can
> re-load it on demand.

This part seems sensible though :-)

> Voila - you have something potentially expensive that you run once, and
> then you have a matrix that can be edited by the sysadmin later and just
> re-loaded at each boot.. That sounds pretty optimal, especially in the
> sense that it allows the sysadmin to tweak things depending on the use of
> the box is he really wants to.
> 
> Hmm? Or am I just totally on crack?
> 
> Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Industry db benchmark result on recent 2.6 kernels

[Kevin Puetz]

Linus Torvalds wrote:

 
 
 On Fri, 1 Apr 2005, Chen, Kenneth W wrote:
 
 Paul, you definitely want to check this out on your large numa box.  I
 booted a kernel with this patch on a 32-way numa box and it took a long
  time to produce the cost matrix.
 
 Is there anything fundamentally wrong with the notion of just initializing
 the cost matrix to something that isn't completely wrong at bootup, and
 just lettign user space fill it in?

Wouldn't getting rescheduled (and thus having another program trash the
cache on you) really mess up the data collection though? I suppose by
spawning off threads, each with a fixed affinity and SCHED_FIFO one could
hang onto the CPU to collect the data. But then it's not (a lot) different
than doing it in-kernel.
 
 Then you couple that with a program that can do so automatically (ie
 move the in-kernel heuristics into user-land), and something that can
 re-load it on demand.

This part seems sensible though :-)

 Voila - you have something potentially expensive that you run once, and
 then you have a matrix that can be edited by the sysadmin later and just
 re-loaded at each boot.. That sounds pretty optimal, especially in the
 sense that it allows the sysadmin to tweak things depending on the use of
 the box is he really wants to.
 
 Hmm? Or am I just totally on crack?
 
 Linus


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Kevin Puetz]

Mark Fortescue wrote:

> Hi Greg,
> 
> If you read the Linux Kernel header file "linux/module.h", there is a
> section about Licenses. If "Proprietary" licences are not leagal, then why
> are they supported ?

Because it does want to let module authors tell the truth, however bleak.
The GPL is quite unambiguous on the subject - the answer is "not allowed".
But the GPL is a copyright license, not an EULA-style contract. If you feel
confident that you can defend a case claiming that your driver was a
derived work, it may not be necessary to agree to the terms at all. Only if
the additional rights granted by GPL (such as the right to distribute
derived works) are required, are you forced to accept it's terms in
exchange for such rights. 

There are at least some who grudgingly accept that it may be possible to
write drivers which are not derived works, at least if they stick to a
interfaces which are widespread and in not specific to Linux. This is
arguably a weakness of the GPL-as-copyright-license, but given the ideals
it represents, arguing to strengthen the laws would be most
counterproductive :-)

> The implication of providing support for them in the header file is that
> it is leagal to create and supply them.

This is certainly something that could be argued from, but I don't know how
successful you it would be. Only a court case could tell.

> I am porting a driver to Linux for a third party. I do not know if they
> whish to release the Linux driver under GPL so I have assumed (because of
> the nature of the hardware) that they do not whish to. I will discus this
> matter with them when I have finnished the driver.

I would suggest you discuss it now; they take a while to get legal advice
and make their decision.

> The use of header files to build a propriatory object files/binaries or
> the use of GCC to compile such a file does not breach GPL as if it did,
> GCC and GLIBC would not be available for non GPL platforms and it would
> not be posible to provide propriatory code for use in a Linux/GNU
> environment.

glibc and libgcc are not under a vanilla GPL. gcc itself is GPL, but it's
fairly well accepted that the output of a tool is not a derived work and
does not fall under that tool's copyright. Otherwise microsoft would be
pocketing a slice of the royalties on everything written using Word. Even
they haven't been that bold yet :-) In any case, these licenses carry
specific exemptions allowing proprietary use. This is a deliberate choice
on the part of their maintainers.

> The Linux Kernel internal APIs are not mensioned in the Kernel GPL so it
> can be argued quite reasonably that the APIs are not coverd by the GPL.

I fail to see how this is even relevent. The kernel COPYING file
specifically states the widely held (I won't claim universal - there's
bound to be someone who would otherwise disagree) belief that the syscall
interface is sufficiently generic; namely, that proprietary use at that
level does not carry any implication that the proprietary component is a
derived work. But this is only a clarification; it does this as the GPL's
interpretation is quite broad. Nothing specific is said about internal
kernel API, so it's covered by the GPL.

> With regard to derived work - mensioned in a number of responses, a new
> driver ported from MS Windows is derived from the Windows Driver not the
> Linux Kernel. If it can be shown that there are sections of code in the

This is the sort of claim that nVidia and ATI make - that the proprietary
portions are not derived works. The fact that they are portable across
multiple OSes, make use of only basic OS services, and predate the linux
port, are reasonably good arguments to that effect. Assuming they aren't
just crazy (which seems a good assumption) they apparently think they can
win if anyone ever challenges them. Seemingly, so do most of the people
complaining, since no court case has yet appeared about it.

> new driver that have been coppied from other Linux drivers, then there is
> a good argument with regard to derived code but it would still be very
> difficult to prove that this code had not been written totally
> independantly from the Linux drivers containing the same or similar code.
> In addition the driver is being built as a module, out side of the kernel
> source tree and as a result can be considered to be separate enterty to

Built inside or outside is not a particularly compelling argument, though it
certainly would be worth a mention if trying to put a case together.

> the kernel. If it was required to be built into the kernel as apposed to
> being a Kernel Module then it would be totally different and the driver
> would need to be GPL.

It wouldn't be all that different. Just another point of evidence in the
decision of whether or not the addition was a derived work.

> The hardware that this driver is being written for is low volume, very
> specialised (with regard to its application). The driver will only be of

And this has 

Re: Can't use SYSFS for Proprietry driver modules !!!.

[Kevin Puetz]

Mark Fortescue wrote:

 Hi Greg,
 
 If you read the Linux Kernel header file linux/module.h, there is a
 section about Licenses. If Proprietary licences are not leagal, then why
 are they supported ?

Because it does want to let module authors tell the truth, however bleak.
The GPL is quite unambiguous on the subject - the answer is not allowed.
But the GPL is a copyright license, not an EULA-style contract. If you feel
confident that you can defend a case claiming that your driver was a
derived work, it may not be necessary to agree to the terms at all. Only if
the additional rights granted by GPL (such as the right to distribute
derived works) are required, are you forced to accept it's terms in
exchange for such rights. 

There are at least some who grudgingly accept that it may be possible to
write drivers which are not derived works, at least if they stick to a
interfaces which are widespread and in not specific to Linux. This is
arguably a weakness of the GPL-as-copyright-license, but given the ideals
it represents, arguing to strengthen the laws would be most
counterproductive :-)

 The implication of providing support for them in the header file is that
 it is leagal to create and supply them.

This is certainly something that could be argued from, but I don't know how
successful you it would be. Only a court case could tell.

 I am porting a driver to Linux for a third party. I do not know if they
 whish to release the Linux driver under GPL so I have assumed (because of
 the nature of the hardware) that they do not whish to. I will discus this
 matter with them when I have finnished the driver.

I would suggest you discuss it now; they take a while to get legal advice
and make their decision.

 The use of header files to build a propriatory object files/binaries or
 the use of GCC to compile such a file does not breach GPL as if it did,
 GCC and GLIBC would not be available for non GPL platforms and it would
 not be posible to provide propriatory code for use in a Linux/GNU
 environment.

glibc and libgcc are not under a vanilla GPL. gcc itself is GPL, but it's
fairly well accepted that the output of a tool is not a derived work and
does not fall under that tool's copyright. Otherwise microsoft would be
pocketing a slice of the royalties on everything written using Word. Even
they haven't been that bold yet :-) In any case, these licenses carry
specific exemptions allowing proprietary use. This is a deliberate choice
on the part of their maintainers.

 The Linux Kernel internal APIs are not mensioned in the Kernel GPL so it
 can be argued quite reasonably that the APIs are not coverd by the GPL.

I fail to see how this is even relevent. The kernel COPYING file
specifically states the widely held (I won't claim universal - there's
bound to be someone who would otherwise disagree) belief that the syscall
interface is sufficiently generic; namely, that proprietary use at that
level does not carry any implication that the proprietary component is a
derived work. But this is only a clarification; it does this as the GPL's
interpretation is quite broad. Nothing specific is said about internal
kernel API, so it's covered by the GPL.

 With regard to derived work - mensioned in a number of responses, a new
 driver ported from MS Windows is derived from the Windows Driver not the
 Linux Kernel. If it can be shown that there are sections of code in the

This is the sort of claim that nVidia and ATI make - that the proprietary
portions are not derived works. The fact that they are portable across
multiple OSes, make use of only basic OS services, and predate the linux
port, are reasonably good arguments to that effect. Assuming they aren't
just crazy (which seems a good assumption) they apparently think they can
win if anyone ever challenges them. Seemingly, so do most of the people
complaining, since no court case has yet appeared about it.

 new driver that have been coppied from other Linux drivers, then there is
 a good argument with regard to derived code but it would still be very
 difficult to prove that this code had not been written totally
 independantly from the Linux drivers containing the same or similar code.
 In addition the driver is being built as a module, out side of the kernel
 source tree and as a result can be considered to be separate enterty to

Built inside or outside is not a particularly compelling argument, though it
certainly would be worth a mention if trying to put a case together.

 the kernel. If it was required to be built into the kernel as apposed to
 being a Kernel Module then it would be totally different and the driver
 would need to be GPL.

It wouldn't be all that different. Just another point of evidence in the
decision of whether or not the addition was a derived work.

 The hardware that this driver is being written for is low volume, very
 specialised (with regard to its application). The driver will only be of

And this has no bearing whatsoever on the 

Re: The address displayed by ldd

[Kevin Puetz]

It's the load address of the library, and it's basically not meant to be a
stable value. It will at least depend on the load order and size of the
libraries, and it may in fact be intentionally randomized each run as a
security measure against ret2libc type attacks (PaX, execshield, etc all do
this, as does prelink everytime it re-prelinks libraries). It's entirely
plausible for it to change from run to run, much less machine to machine.

[EMAIL PROTECTED] wrote:

> Hi,
> 
> I have a small question,
> I am not sure if it belongs to kernel.
> I often use ldd to find librarys needed.
> In some systems,the address display by ldd not
> changes,
> But in other systems, it changes.
> 
> What is the reason of the difference?
> Is it cause by some setting in kernel?
> 
> Thanks in advance.
> gan
> 
> 
> 
> 
> __
> Do you Yahoo!?
> Yahoo! Mail - Find what you need with new enhanced search.
> http://info.mail.yahoo.com/mail_250


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The address displayed by ldd

[Kevin Puetz]

It's the load address of the library, and it's basically not meant to be a
stable value. It will at least depend on the load order and size of the
libraries, and it may in fact be intentionally randomized each run as a
security measure against ret2libc type attacks (PaX, execshield, etc all do
this, as does prelink everytime it re-prelinks libraries). It's entirely
plausible for it to change from run to run, much less machine to machine.

[EMAIL PROTECTED] wrote:

 Hi,
 
 I have a small question,
 I am not sure if it belongs to kernel.
 I often use ldd to find librarys needed.
 In some systems,the address display by ldd not
 changes,
 But in other systems, it changes.
 
 What is the reason of the difference?
 Is it cause by some setting in kernel?
 
 Thanks in advance.
 gan
 
 
 
 
 __
 Do you Yahoo!?
 Yahoo! Mail - Find what you need with new enhanced search.
 http://info.mail.yahoo.com/mail_250


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Linux Kernel Subversion Howto

[Kevin Puetz]

Olaf Dietsche wrote:

> Stelian Pop <[EMAIL PROTECTED]> writes:
> 
>> I must test this...), plus 600 MB per working copy.
> 
> If you use svk  for the client side, there's
> (almost?) no overhead.
> 
> Regards, Olaf.

erm, svk is cool and all, but it keeps a local repository mirror (not
necessarily full I suppose, but usually it is). So it's *much* heavier on
the client side than normal svn. Pays off in several ways, but just because
it keeps it's weight in the depot folder instead of the wc folder doesn't
make it ligher (unless you use several wc's I suppose).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VM disk cache behavior.

[Kevin Puetz]

Andy Isaacson wrote:

> Most likely is that your app isn't behaving in a cache-friendly way.ÂÂIf
> your file will fit in memory, just fault it in sequentially (wc -l file)
> and then your app should cook.ÂÂIfÂyou'reÂnotÂgoingÂtoÂfitÂinÂmemory,
> the vm caching will probably only help if you have some reuse; you could
> develop a pre-faulter to get your IO started ahead of time, but that's
> generally nontrivial.

Of course, what's non-trivial is predicting your upcoming I/O pattern
(unless it's not actually random at all, just messy). Calling madvise to
prefault it is pretty easy if you actually do know what you'll want in the
near future.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VM disk cache behavior.

[Kevin Puetz]

Andy Isaacson wrote:

 Most likely is that your app isn't behaving in a cache-friendly way.If
 your file will fit in memory, just fault it in sequentially (wc -l file)
 and then your app should cook.Ifyou'renotgoingtofitinmemory,
 the vm caching will probably only help if you have some reuse; you could
 develop a pre-faulter to get your IO started ahead of time, but that's
 generally nontrivial.

Of course, what's non-trivial is predicting your upcoming I/O pattern
(unless it's not actually random at all, just messy). Calling madvise to
prefault it is pretty easy if you actually do know what you'll want in the
near future.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Linux Kernel Subversion Howto

[Kevin Puetz]

Olaf Dietsche wrote:

 Stelian Pop [EMAIL PROTECTED] writes:
 
 I must test this...), plus 600 MB per working copy.
 
 If you use svk http://svk.elixus.org/ for the client side, there's
 (almost?) no overhead.
 
 Regards, Olaf.

erm, svk is cool and all, but it keeps a local repository mirror (not
necessarily full I suppose, but usually it is). So it's *much* heavier on
the client side than normal svn. Pays off in several ways, but just because
it keeps it's weight in the depot folder instead of the wc folder doesn't
make it ligher (unless you use several wc's I suppose).

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/