Re: [RFT][patch] Scheduling for HTT and not only

On 17.02.2012 18:53, Arnaud Lacombe wrote:
> On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin<mav_at_freebsd.org>  wrote:
>> On 02/15/12 21:54, Jeff Roberson wrote:
>>> On Wed, 15 Feb 2012, Alexander Motin wrote:
>>>> I've decided to stop those cache black magic practices and focus on
>>>> things that really exist in this world -- SMT and CPU load. I've
>>>> dropped most of cache related things from the patch and made the rest
>>>> of things more strict and predictable:
>>>> http://people.freebsd.org/~mav/sched.htt34.patch
>>>
>>> This looks great. I think there is value in considering the other
>>> approach further but I would like to do this part first. It would be
>>> nice to also add priority as a greater influence in the load balancing
>>> as well.
>>
>> I haven't got good idea yet about balancing priorities, but I've rewritten
>> balancer itself. As soon as sched_lowest() / sched_highest() are more
>> intelligent now, they allowed to remove topology traversing from the
>> balancer itself. That should fix double-swapping problem, allow to keep some
>> affinity while moving threads and make balancing more fair. I did number of
>> tests running 4, 8, 9 and 16 CPU-bound threads on 8 CPUs. With 4, 8 and 16
>> threads everything is stationary as it should. With 9 threads I see regular
>> and random load move between all 8 CPUs. Measurements on 5 minutes run show
>> deviation of only about 5 seconds. It is the same deviation as I see caused
>> by only scheduling of 16 threads on 8 cores without any balancing needed at
>> all. So I believe this code works as it should.
>>
>> Here is the patch: http://people.freebsd.org/~mav/sched.htt40.patch
>>
>> I plan this to be a final patch of this series (more to come :)) and if
>> there will be no problems or objections, I am going to commit it (except
>> some debugging KTRs) in about ten days. So now it's a good time for reviews
>> and testing. :)
>>
> is there a place where all the patches are available ?

All my scheduler patches are cumulative, so all you need is only the 
last mentioned here sched.htt40.patch.

But in some cases, especially for multi-socket systems, to let it show 
its best, you may want to apply additional patch from avg_at_ to better 
detect CPU topology:
https://gitorious.org/~avg/freebsd/avgbsd/commit/6bca4a2e4854ea3fc275946a023db65c483cb9dd

> I intend to run
> some tests on a 1x2x2 (atom D510), 1x4x1 (core-2 quad), and eventually
> a 2x8x2 platforms, against r231573. Results should hopefully be
> available by the end of the week-end/middle of next week[0].
>
> [0]: the D510 will likely be testing a couple of Linux kernel over the
> week-end, and a FreeBSD run takes about 2.5 days to complete.

-- 
Alexander Motin