new DragonFly-3.2 scheduler and PostgreSQL comparision with FreeBSD 9.1-RC1

[Alexander Motin]

On 14.10.2012 12:47, Andriy Gapon wrote:
> on 14/10/2012 00:27 Pedro Giffuni said the following:
>> Actually ...
>>
>> On 10/13/2012 13:38, Jakub Lach wrote:
>>> I'm not at all up to date with DragonFly, so does anybody know
>>> what did they change so spectacularly between 3.0/3.2?
>>>
>> Their explanation of the changes is here:
>>
>> http://www.shiningsilence.com/dbsdlog/2012/09/19/10403.html
>
>  From the article:
>
>        (3) It will detect process block/wakeup events which e.g. tie two
> 	  processes together, and will try to move the process pairs closer
> 	  to each other using that information.
>
> 	  For example, if you have many postgres clients and servers on a
> 	  large server, enough to load down all cores, the client and
> 	  server pairs will be localized to the same socket, thus making
> 	  use of chip caches to facilitate communications between the two
> 	  processes.
>
> This sounds like a nice heuristic.  Currently our code unintentionally does the
> opposite quite often.

Yes, that is true. Present ULE code puts too much attention to the 
cache/socket load balance and affinity to previous run places. That way 
is quite simple and straightforward. More sophisticated way would be to 
have some kind of thresholds (for example, in number of context switches 
per second) where caller thread cache affinity becomes more important 
then callee thread's previous cache affinity. But I guess it can be 
quite application-specific. In mentioned case of PostgreSQL I guess 
there could be cases when cache affinity between server processes is 
more important then affinity between servers and clients.

-- 
Alexander Motin