Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Mar 2008 02:16:30 -1000 (HST)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        arch@freebsd.org
Subject:   Getting rid of the static msleep priority boost
Message-ID:  <20080307020626.G920@desktop>

next in thread | raw e-mail | index | archive | help
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.  The 
basic problem is that a user thread will be woken with a kernel priority 
thus allowing it to preempt a thread running on any processor with a 
lesser priority.  The lesser priority thread may in fact hold some 
resource that the higher priority thread requires.  Thus we context switch 
several times and perhaps go through priority propagation as well.

I have verified that disabling these static priority boosts entirely fixes 
the performance problem I've run into on at least one workload.  There are 
probably others that it helps and hopefully we can discover that.

I'd like to know if anyone has a strong preference to keep this feature. 
It is likely that it helps in some interactive situations.  I'm not sure 
how much however.  I propose that we make a sysctl that disables it and 
turn it off by default.  If we see complaints on current@ we can suggest 
that they toggle the sysctl to see if it alleviates problems.

Based on feedback from that experiment and some testing we can then choose 
a few options:

1)  Disable the static boosts entirely.  Leave kernel priorities for 
kernel threads and priority propagation.  Most other kernels do this. 
Would make my life in ULE much easier as well.

2)  Leave the support for static boosts but remove it from all but a few 
key locations.  Leaving it in the api would give some flexibility but 
might confuse developers.

3)  Leave things as they are.  undesirable.

I'm leaning towards #2 based on the information I have presently.  This is 
almost a significant change to historic BSD behavior so we might want to 
tread lightly.

Thanks,
Jeff



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080307020626.G920>