[GE users] Default CPU core binding

dagru daniel.x.gruber at oracle.com
Wed Oct 13 22:00:33 BST 2010


Am Dienstag, den 12.10.2010, 23:39 +0200 schrieb reuti:
> Hi,
> 
> Am 12.10.2010 um 23:09 schrieb icaci:
> 
> >> <snip>
> >> 9926 ms04      39  19  3756  292  228 R   25  0.0   0:19.31 ever                                                                                                                              
> >> 9927 ms04      39  19  3756  292  228 R   25  0.0   0:19.31 ever                                                                                                                              
> >> 9925 ms04      39  19  3756  288  228 R   25  0.0   0:19.30 ever                                                                                                                              
> >> 9928 ms04      39  19  3756  292  228 R   25  0.0   0:19.30 ever 
> >> 
> >> for 4 forks of an endless loop in one and the same jobscript when submitted with `qsub -binding linear:1 demo.sh`. Well, the funny thing is that with this kernel version I still get a load of 4, despite the fact that all 4 forks are bound to one core. Should it really be four?
> >> 
> > 
> > Load measures the average number of entities in the kernel's running tasks queue. It is mostly but not always equal to the average CPU load in %'s. E.g. if you have 12 processes waiting on uninterruptible NFS I/O in "D" state (as shown by ps), you will get load value of about 12.0 and CPU usage of about 0%.
> > 
> > So yes, it should be four, at least on Linux.
> 
> yes, correct. But about this I tried to start a discussion already some time ago:
> 
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=278735
> 
> How to use the load as threshold in such a situation any longer? Besides the native implementation being the length of the run queue, in my opinion there is something missing and a need to have something new, either "load by SGE jobs" (on SGE level) or "load per core" (on a Linux level). For now you can't tell much about the situation of a machine when you look only at the load.

That's interesting also for the case of queue sort method load.
I would agree that in such a situation the load per host makes not 
much sense. IMHO when all jobs are bound on an execution host even 
the load per OS processor would not be from interest, because the
different run queue lengths wouldn't have much influence to the 
computational throughput of other cores (with the exception of the 
automatic overclocking feature of some processors). 
The bottleneck could be a shared resource (like high level caches and
I/O). Therefore I could imagine that the average amount of waiting (for
I/O) processes per host could be better as a queue load sort method for
example. Would this make more sense? 

Daniel

> 
> -- Reuti 
> 
> 
> > Hristo
> > 
> >> -- Reuti
> >> 
> >> 
> >>> Thanks,
> >>> 
> >>> Chris
> >>> 
> >>> 
> >>> --
> >>> Dr Chris Jewell
> >>> Department of Statistics
> >>> University of Warwick
> >>> Coventry
> >>> CV4 7AL
> >>> UK
> >>> Tel: +44 (0)24 7615 0778
> >>> 
> >>> ------------------------------------------------------
> >>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=285595
> >>> 
> >>> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
> >>> 
> >> 
> >> ------------------------------------------------------
> >> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=286632
> >> 
> >> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
> > 
> > ------------------------------------------------------
> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=286693
> > 
> > To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
> >
> 
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=286700
> 
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=286946

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list