idle priority scheduling broken in 7.0-BETA4
Jeff Roberson
jroberson at chesapeake.net
Thu Jan 3 15:35:46 PST 2008
On Fri, 4 Jan 2008, Peter Jeremy wrote:
> On Wed, Jan 02, 2008 at 03:31:34AM -1000, Jeff Roberson wrote:
>> ah, I'm sorry. the new line with PRI_FIFO should read PRI_FIFO_BIT. I
>> tested the patch but not with any idle prio tasks that run forever.
>
> That seems to work and I don't see any problems with it. There were
> seven watchdog restarts over about 3/4 hr whilst the system was doing
> a buildworld but this is probably not completely unreasonable.
This is a boinc watchdog? The client just didn't get to run for too long
during the buildworld?
>
> One oddity I noticed is that setiathome (unlike einstein at home) has one
> thread that seems to have lost the idle bit (though that thread appears
> to just idle). This is equivalent to a process increasing its priority
> so I wouldn't have expected it.
If you notice the second thread is sitting in nanosleep. In BSD there is
a static priority boost after sleeping that is revoked when you wake up.
This can also happen from priority propagation if you grab a lock that a
high priority thread wants.
>
> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND
> 51503 boinc 171 i31 39944K 33052K RUN 3:43 100.00% setiathome-5.27.i
> 51503 boinc 8 19 39944K 33052K nanslp 3:43 0.00% setiathome-5.27.i3
> 10 root 171 ki31 0K 8K RUN 2:51 0.00% idle
> 4 root -8 - 0K 8K - 0:54 0.00% g_down
>
> Let me know if you really want to get boinc working for yourself.
If there are any further complaints I will. Is there any chance you could
also try it with nice +20 or nice +10 and report how the system behaves?
Thanks!
Jeff
>
> --
> Peter Jeremy
> Please excuse any delays as the result of my ISP's inability to implement
> an MTA that is either RFC2821-compliant or matches their claimed behaviour.
>
More information about the freebsd-current
mailing list