hi
what is meant by processor affinity?
if somebody know anythiung about it?
or tell me the correct mailing list...
thanks
ankit
________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
On Tue, Sep 28, 2004 at 01:25:17PM +0100, Ankit Jain wrote:
> hi
>
> what is meant by processor affinity?
$ man sched_setaffinity
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
On Tue, 28 Sep 2004 13:25:17 +0100 (BST), Ankit Jain
<[email protected]> wrote:
> what is meant by processor affinity?
Affinity means that a process has an affinity for a particular subset
of the available CPUs within a particular system - it wishes to run
only on these processors. Linux supports hard processor affinity and
process migration to enforce such demands which get be made using the
POSIX sched_[set|get]param calls.
Robert Love has written an excellent book entitled Linux Kernel
Development, it's not expensive and very worthwhile. Chapter 3 is
entitled Scheduling and it explains process affinity as well as
process migration and the concept of migration threads as used within
the Linux kernel to enforce policy in the implmentation.
I suggest also that you consider joining the Kernel Newbies mailing
list, newly revived and now with working signup page over at
http://www.kernelnewbies.org/
Jon.
Ankit Jain wrote:
> hi
>
> what is meant by processor affinity?
>
> if somebody know anythiung about it?
>
> or tell me the correct mailing list...
>
> thanks
>
> ankit
>
Its the ability to bind a process to subset of processors.
Neil
> ________________________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping"
> your friends today! Download Messenger Now
> http://uk.messenger.yahoo.com/download/index.html
> -
> 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/
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
Ankit Jain wrote:
Here's a real good description in a patent owned by Novell on the subject.
Jeff
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=2&f=G&l=50&co1=AND&d=ptxt&s1=merkey.INZZ.&OS=IN/merkey&RS=IN/merkey
>hi
>
>what is meant by processor affinity?
>
>if somebody know anythiung about it?
>
>or tell me the correct mailing list...
>
>thanks
>
>ankit
>
>________________________________________________________________________
>Yahoo! Messenger - Communicate instantly..."Ping"
>your friends today! Download Messenger Now
>http://uk.messenger.yahoo.com/download/index.html
>-
>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/
>
>
>
On Tue, 2004-09-28 at 08:04 -0600, Jeff V. Merkey wrote:
> Here's a real good description in a patent owned by Novell on the subject.
>
> Jeff
>
> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=2&f=G&l=50&co1=AND&d=ptxt&s1=merkey.INZZ.&OS=IN/merkey&RS=IN/merkey
Wow, I never knew about that.
But guess who wrote the affinity system calls? :)
Robert Love
Robert Love wrote:
>On Tue, 2004-09-28 at 08:04 -0600, Jeff V. Merkey wrote:
>
>
>
>>Here's a real good description in a patent owned by Novell on the subject.
>>
>>Jeff
>>
>>http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=2&f=G&l=50&co1=AND&d=ptxt&s1=merkey.INZZ.&OS=IN/merkey&RS=IN/merkey
>>
>>
>
>Wow, I never knew about that.
>
>But guess who wrote the affinity system calls? :)
>
> Robert Love
>
>
>
I wrote them first, and coined the term.
:-)
Jeff
>
>
>
On Maw, 2004-09-28 at 17:02, Jeff V. Merkey wrote:
> >>http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=2&f=G&l=50&co1=AND&d=ptxt&s1=merkey.INZZ.&OS=IN/merkey&RS=IN/merkey
> >Wow, I never knew about that.
> >
> >But guess who wrote the affinity system calls? :)
> I wrote them first, and coined the term.
Cute but GCOS3 had affinity syscalls for batch processing in the 1970's
and I don't believe it was original even then.
Alan Cox wrote:
>On Maw, 2004-09-28 at 17:02, Jeff V. Merkey wrote:
>
>
>>>>http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=2&f=G&l=50&co1=AND&d=ptxt&s1=merkey.INZZ.&OS=IN/merkey&RS=IN/merkey
>>>>
>>>>
>>>Wow, I never knew about that.
>>>
>>>But guess who wrote the affinity system calls? :)
>>>
>>>
>
>
>
>>I wrote them first, and coined the term.
>>
>>
>
>Cute but GCOS3 had affinity syscalls for batch processing in the 1970's
>and I don't believe it was original even then.
>
>
Using them for Intel Cache affinity was new at the time. Intel SMP
hardware was not readily available at the time and was in
its infancy in 1993 when this was developed. This implementation (like
Linux) was specific to IA32 architecture systems.
Jeff
>-
>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/
>
>
>
On Wed, Sep 29, 2004 at 10:56:51AM -0600, Jeff V. Merkey wrote:
> Using them for Intel Cache affinity was new at the time. Intel SMP
> hardware was not readily available at the time and was in
> its infancy in 1993 when this was developed. This implementation (like
> Linux) was specific to IA32 architecture systems.
The Linux implementation works on about a dozen plattforms, or how
many smp ports we have these days..
Christoph Hellwig wrote:
>On Wed, Sep 29, 2004 at 10:56:51AM -0600, Jeff V. Merkey wrote:
>
>
>>Using them for Intel Cache affinity was new at the time. Intel SMP
>>hardware was not readily available at the time and was in
>>its infancy in 1993 when this was developed. This implementation (like
>>Linux) was specific to IA32 architecture systems.
>>
>>
>
>The Linux implementation works on about a dozen plattforms, or how
>many smp ports we have these days..
>
>
>
>
In it's early beginnings, Linux was IA32 based. A pretty cool idea at
the time. The patent took ten years to issue due to all the prior
art claims. I remember Novell's lawyers bringing me reams of prior art
to review during the initial work to verify there was no prior
art in the field. Apparently, this was for first affinity patent on SMP
architecture systems filed, or it would not have issued. Anyway, I
provided it as a reference since it is the first patent on SMP affinity
scheduling and methods for the very interested person who asked. And
yes, Linux
appears to infringe it, but since Novell is pro-Linux, I don't think it
matters.
:-)
Jeff
On Wed, 29 Sep 2004 13:24:42 -0600, Jeff V. Merkey <[email protected]> wrote:
> Anyway, I
> provided it as a reference since it is the first patent on SMP affinity
> scheduling and methods for the very interested person who asked. And
> yes, Linux
> appears to infringe it, but since Novell is pro-Linux, I don't think it
> matters.
Still it's probably worth knowing it might be an issue someday. What's
Novell's position on patents they hold involving the kernel? I'm too
lazy to go hunting for it (rml might well know).
Jon.
Jon Masters wrote:
>On Wed, 29 Sep 2004 13:24:42 -0600, Jeff V. Merkey <[email protected]> wrote:
>
>
>
>>Anyway, I
>>provided it as a reference since it is the first patent on SMP affinity
>>scheduling and methods for the very interested person who asked. And
>>yes, Linux
>>appears to infringe it, but since Novell is pro-Linux, I don't think it
>>matters.
>>
>>
>
>Still it's probably worth knowing it might be an issue someday. What's
>Novell's position on patents they hold involving the kernel? I'm too
>lazy to go hunting for it (rml might well know).
>
>Jon.
>
>
>
Since they are hiring as many top Linux folks as possible, and they have
invested their entire future in Linux, I think
their actions speak so loud, it doesn't matter what your hearing from
them. Novell's position (from my experience)
it that they will take whatever steps they feel necessary to protect
their circle (as evidenced by an illegal search of
my home by Novell Security Employees (not law enforcement 8 Novell
employees and a sheriff) ) along with spending
17 million dollars in litigation costs to keep me out of the computer
business for almost 4 years by crushing me, my
family, and any business I tried to start, and ruining my life and my
marriage with my previous wife of 24 years).
If you are in their circle, they will fight for you to the death, and
breaking the rules doesn't bother them.
If you are outside their circle ........ you should feel very safe and
comfortable.
Linux is in their circle at present. I think you should weigh the
options and make the appropriate decisions
when choosing to deal with them.
Jeff
On Wed, 29 Sep 2004 13:43:32 -0600, Jeff V. Merkey <[email protected]> wrote:
> Since they are hiring as many top Linux folks as possible, and they have
> invested their entire future in Linux, I think their actions speak so loud,
I only asked because I'd not heard of an official patent position from
them (but I've not looked) and I wondered if someone happened to know
- words are completely meaningless.
<snip>
Wow, tha'ts one bitter mail you sent. Sorry to hear about it but I'd
rather not start a general discussion about big business practices and
Novell - just interested in the patent situation.
Jon.
Jon Masters wrote:
>On Wed, 29 Sep 2004 13:43:32 -0600, Jeff V. Merkey <[email protected]> wrote:
>
>
>
>>Since they are hiring as many top Linux folks as possible, and they have
>>invested their entire future in Linux, I think their actions speak so loud,
>>
>>
>
>I only asked because I'd not heard of an official patent position from
>them (but I've not looked) and I wondered if someone happened to know
>- words are completely meaningless.
>
><snip>
>
>Wow, tha'ts one bitter mail you sent. Sorry to hear about it but I'd
>rather not start a general discussion about big business practices and
>Novell - just interested in the patent situation.
>
>Jon.
>
>
>
Just letting you have a little insight into what their position might
be. It's not bitter, it's
factual, and I got over Novell a long time ago. They will probably
ignore you for now, but
in the future, if Linux contains IP from sources they consider theirs,
it would be possible
for them to shut out competitors without a license from them. Not only
on this topic, but
any other area their employees have contributed for which they hold
patents. This case may
be a special one, but anytime you use patented materials are even areas
where there is a doubt
there is exposure. I have a release from them and I can use any IP I
retained in a non-tangible
form that would have been theirs. So I can use this patent without
concern of infringement
claims. But since I did not instrument the affinity code in Linux, it's
not protected this way.
NWFS is protected this way and people can use it without fear of claims
from Novell.
Jeff
Jeff V. Merkey wrote:
> Alan Cox wrote:
>
>> On Maw, 2004-09-28 at 17:02, Jeff V. Merkey wrote:
>>
>>
>>>>> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=2&f=G&l=50&co1=AND&d=ptxt&s1=merkey.INZZ.&OS=IN/merkey&RS=IN/merkey
>>>>>
>>>>>
>>>>
>>>> Wow, I never knew about that.
>>>>
>>>> But guess who wrote the affinity system calls? :)
>>>>
>>
>>
>>
>>
>>> I wrote them first, and coined the term.
>>
>>
>> Cute but GCOS3 had affinity syscalls for batch processing in the 1970's
>> and I don't believe it was original even then.
>>
>>
>
> Using them for Intel Cache affinity was new at the time. Intel SMP
> hardware was not readily available at the time and was in
> its infancy in 1993 when this was developed.
That is amazingly specific - I suppose using it for cache affinity on
earlier processors wouldn't count :)
Joking aside, this doesn't seem like it would apply to Linux's scheduler.
We don't use a global queue, and we don't implement hard affinities with
local queues, but with a specific bitmask of cpus.
Of course, I don't really have any idea how to interpret patents...
[email protected] wrote:
> On Thu, Sep 30, 2004 at 12:39:12PM +1000, Nick Piggin wrote:
>>Of course, I don't really have any idea how to interpret patents...
^^^
keeping that in mind
>
> The implementation in NetWare and the Implementation in Linux are
> similiar but not identical, but they are close enough. CPU bitmasks were
> used. The best apporach would be for someone to locate prior art in the
> field and challenge the patent in the event any claims were ever brought
> or avoid the same methods.
It seems that the actual patent describes the implementation of the
scheduler that achieves this. And in it, the method used is a locked
global queue and unlocked local queues. But anyway.
> I was able to achieve greater than
> 100% scaling per processor due to Intel's quirky cache behavior.
And probably most cache behaviours. If you have a set of tasks with
a working set larger than the cache of 1 processor but that can be
divided to fit into the cache of 2, then you're laughing.
More than 1 CPU can dramatically lower task switch (and mm switch)
rates in ideal situations, too.
> If
> you can get a small subset of code in the cache controllers for
> processes through hueristics (i.e. guessing) additive processor
> scaling can be increased dramatically due to taking advantage
> of the L1 and L2 proceesor caches. Linux is somewhat crude
> from an SMP perspective even today, although it has an impressive
> array of hardware support for SMP systems and architectures, but
> based on the small number of processes than run on average (< 100)
> this technique would work on Linux.
>
Well it has pretty strong CPU affinity, and roughly distributes
load evenly over CPUs. What more do you want? :)