Morten Reistad wrote:
> In article <E1r7l.250857$Mh5.218...
> Stephen Fuld <S.F...
>> Jean-Marc Bourguet wrote:
>>> Stephen Fuld <S.F...
>>>> Terje Mathisen wrote:
>>>>> Stephen Fuld wrote:
>>>>>> Terje Mathisen wrote:
>>>>>>> There is nothing stopping Intel from making hybrid chips, with maybe
>>>>>>> 1-4 Core2 class "fast" cores and 30-60 LRB-style
>>>>>>> power-efficient/throughput-optimized cores.
>>>>>> Yes, but as Anton pointed out, the OSs will take time to figure out how
>>>>>> to deal with this well.
>>>>> Various bleeding-edge Linux versions and probably *BSD as well will
>>>>> support such a hybrid chip from day one, while Microsoft's Windows 7 (or
>>>>> 8, 9 etc) will need major surgery and significant lead time.
>>>> I've been thinking about this a little. If the number of "threads"
>>>> (i.e. units of work requesting CPU time whether they be single thread
>>>> processes or threads of a multi-thread process) is =< the number of fast
>>>> processors, then it seems trivial. But if the number of requesters is
>>>> greater than the number of fast processors, is there a general algorithm
>>>> for the OS to decide (without any information from the requesters
>>>> themselves) which ones are given time on the fast processors? ISTM this
>>>> could get complex very quickly and I don't see an easy solution.
>>> Migrate to the fast processors the process which use their full time slice
>>> without yielding it back -- and migrate of those which aren't consuming
>>> theirs -- seems an obvious first approach. It's in fact the same processes
>>> which get benefit from a longer time slice but less often.
>> I think this has some problems. For example, what if more tasks are
>> compute bound than you have fast processors? Also I guess you could
>> have a situation where you were running something like protein folding
>> at home which is a background task that soaks up all available CPU time.
>> A naive algorithm could then schedule it on the fast core when in
>> fact it doesn't contribute the higher priority work the customer really
>> wants done.
> Isn't this what the priority (PR in top, PRI in ps in Linux) field is for?
Probably. But at least on my current Windows system, I just checked and
the overwhelming majority of the tasks are at priority "normal". Note
that this includes most of the Windows services as well as the
"background" tasks that only get control once in a while to check for
updates, etc. So that mechanism seems to rely on the programmer putting
something in his program and understanding enough to be able to do it
intelligently. I am, at best, dubious that most software that people
either buy from the local store or Amazon, or download from some web
site will do this well enough for the system to rely on it.
- Stephen Fuld
(e-mail address disguised to prevent spam)