This is the mail archive of the cygwin-talk mailing list for the cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: interpretation of %CPU in 'procps' output for multi-cpu & hyperthreading


[ Tom, I've Cc'd your personal address just in case you don't check the -talk
list - I'll leave it out of any further posts to this thread (sic!) unless you
specifically ask. ]

On 11 October 2007 19:00, Matthew Woehlke wrote:

> Tom Rodman wrote:

>> I meant to ask:
>> 
>>   Is there a way to prove that a given process with more than 1
>>   thread, must always have all it's threads on a single CPU at
>>   any given time 

  Nope, because it's not the case.  In the absence of restricted affinity, the
OS is free to schedule any ready thread to any free cpu at any time (although
it will try to give a thread a quantum on the same cpu it ran on last time if
possible, since that cpu might still have some of the thread's code or data in
its L1 caches).  There is nothing special about threads happening to be from
the same process or not and no guarantee that they will be on the same cpu -
in fact, it goes to some trouble to distribute the threads within a process
across all cpus.

  There's some general discussion of the scheduler at
http://book.itzero.com/read/microsoft/0507/microsoft.press.microsoft.windows.i
nternals.fourth.edition.dec.2004.internal.fixed.ebook-ddu_html/0735619174/ch06
lev1sec5.html

(aka http://tinyurl.com/yonxs5 )

  See also the comment by "Mike Dimmick" at
http://www.codinghorror.com/blog/archives/000671.html

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]