Date: Thu, 3 Jan 2008 13:37:06 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-current@freebsd.org Subject: Re: idle priority scheduling broken in 7.0-BETA4 Message-ID: <20080103133510.D957@desktop> In-Reply-To: <20080103192104.GS947@server.vk2pj.dyndns.org> References: <20071223092332.GJ25002@server.vk2pj.dyndns.org> <476F81AF.7000505@gmail.com> <20080101190607.B957@desktop> <20080102105049.GA903@server.vk2pj.dyndns.org> <20080102033011.P957@desktop> <20080103192104.GS947@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080103133510.D957>