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

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

[Dave Korn]

[ 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....

Re: %CPU in 'procps' output for multi-cpu & hyperthreading (Thx for help)

[Tom Rodman]

[ a belated thank-you ] 

On Thu 10/11/07 19:52 BST Dave Korn wrote:
> 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.

Thanks sir!

>   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 )

I have the 2005 'Windows Internals' hardcover - I'll read that section;
I appreciate the link.

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

been reading that discussion off and on, because of your link :->

>     cheers,
>       DaveK