Getting rid of the static msleep priority boost

Jeff Roberson jroberson at chesapeake.net
Fri Mar 7 22:50:55 UTC 2008


On Fri, 7 Mar 2008, Kirk McKusick wrote:

>> From: John Baldwin <jhb at freebsd.org>
>> To: Jeff Roberson <jroberson at chesapeake.net>
>> Date: Fri, 7 Mar 2008 08:42:37 -0500
>> Cc: arch at freebsd.org
>> Subject: Re: Getting rid of the static msleep priority boost
>>
>> On Friday 07 March 2008 07:16:30 am Jeff Roberson wrote:
>>> Hello,
>>>
>>> I've been studying some problems with recent scheduler improvements that
>>> help a lot on some workloads and hurt on others.  I've tracked the problem
>>> down to static priority boosts handed out by msleep/cv_broadcastpri.
>>> ...
>>
>> ...
>>
>> This change allows the decision on priority boost to be a scheduler
>> decision to ignore it (so 4BSD could continue to do what it does now,
>> but ULE may ignore it, or ignore certain levels, etc.)
>>
>> --
>> John Baldwin
>
> I strongly agree with John's suggestion. The 4BSD scheduler will continue
> to have its historic behavior (which was `tuned' by careful selection of
> priority boosts) while more sophisticated schedulers like ULE will be able
> to use/ignore the priority boosts based on their better knowledge of system
> behavior.

Yes, this is a good point.  4BSD is starting to fall behind featurewise on 
SMP but we should try to keep it in good working order as it serves as an 
excellent point for comparison.

Eventually as systems with more than 4 cores become standard we're going 
to have to make some decisions regarding its long term fate.  One option 
would be for someone to keep the 4bsd priority scheduling code and couple 
it with the ULE per-cpu load balancing code to keep it going.  However the 
global run-queue is seeing the end of its days.

Thanks,
Jeff

>
> 	Kirk McKusick
>


More information about the freebsd-arch mailing list