Date: Mon, 6 Feb 2012 11:09:21 +0100 From: Gary Jennejohn <gljennjohn@googlemail.com> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: [RFT][patch] Scheduling for HTT and not only Message-ID: <20120206110921.23741ee5@ernst.jennejohn.org> In-Reply-To: <4F2F7B7F.40508@FreeBSD.org> References: <4F2F7B7F.40508@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 06 Feb 2012 09:04:31 +0200 Alexander Motin <mav@FreeBSD.org> wrote: > I've analyzed scheduler behavior and think found the problem with HTT. > SCHED_ULE knows about HTT and when doing load balancing once a second, > it does right things. Unluckily, if some other thread gets in the way, > process can be easily pushed out to another CPU, where it will stay for > another second because of CPU affinity, possibly sharing physical core > with something else without need. > > I've made a patch, reworking SCHED_ULE affinity code, to fix that: > http://people.freebsd.org/~mav/sched.htt.patch > 10.0-CURRENT FreeBSD r231026M: Mon Feb 6 10:40:10 CET 2012 amd64 CPU: AMD Phenom(tm) II X6 1090T Processor (3214.71-MHz K8-class CPU) This patch seems pretty good. Previously I was using SCHED_4BSD. My simple test was "make -j6 buildworld" while loading web pages at the same time and observing the CPU core loading using gkrellm. In general the loads seemed to be more evenly distributed than without the patch. With the old ULE CPU0 seemed to be underutilized, now it's an equal partner. Web pages also loaded quite quickly despite the high load on the cores. I did notice some mouse pointer lag, but it was quite minor. The buildworld time also seemed to be pretty much the same as with 4BSD. Seems like a good start on improving ULE. -- Gary Jennejohn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120206110921.23741ee5>