>>>> 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.
>>>>> Obviously:

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