On 17.02.2012 18:53, Arnaud Lacombe wrote:
On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin<m...@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@ 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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
