Date: Thu, 16 Feb 2012 06:41:31 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: freebsd-hackers@FreeBSD.org, Florian Smeets <flo@FreeBSD.org>, Andriy Gapon <avg@FreeBSD.org> Subject: Re: [RFT][patch] Scheduling for HTT and not only Message-ID: <4F3C88FB.6080006@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.1202150949480.2020@desktop> References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <alpine.BSF.2.00.1202131012270.2020@desktop> <4F3978BC.6090608@FreeBSD.org> <alpine.BSF.2.00.1202131108460.2020@desktop> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <alpine.BSF.2.00.1202150949480.2020@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/15/12 21:54, Jeff Roberson wrote: > On Wed, 15 Feb 2012, Alexander Motin wrote: > >> On 02/14/12 00:38, Alexander Motin wrote: >>> I see no much point in committing them sequentially, as they are quite >>> orthogonal. I need to make one decision. I am going on small vacation >>> next week. It will give time for thoughts to settle. May be I indeed >>> just clean previous patch a bit and commit it when I get back. I've >>> spent too much time trying to make these things formal and so far >>> results are not bad, but also not so brilliant as I would like. May be >>> it is indeed time to step back and try some more simple solution. >> >> 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 have feeling that for timeshare/idle threads balance should take into account not a priority, but a nice level. Priority is very unstable thing that is recalculated each time, while nice it is what really describes how much time thread should get in perspective and those values should be shuffled equally between CPUs. But I haven't thought about specific math yet. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3C88FB.6080006>