Date: Mon, 8 Jul 2002 10:14:17 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Wemm <peter@wemm.org> Cc: Luigi Rizzo <rizzo@icir.org>, Alan Cox <alc@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/vm vm_zeroidle.c Message-ID: <20020708084010.J13539-100000@gamplex.bde.org> In-Reply-To: <20020707211816.C7EF13808@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 7 Jul 2002, Peter Wemm wrote: > Luigi Rizzo wrote: > > While you are on this file: there is a rather tricky bug > > in the priority of the process. > > > > It starts at RTP_PRIO_IDLE, but after the first tsleep > > its priority gets raised to PPAUSE (which is much higher) > > and never gets reset to the proper value. > > > > The effect is that the process runs with very high priority, > > and the only reason you don't notice (or maybe you do) is > > that after a while the process does not have any more > > pages to zero and voluntarily deschedules. > > > > For a fix (rather trivial) have a look at > > > > sys/kern/kern_poll.c:poll_idle() > > > > which does not have the nice property of descheduling > > itself and so makes the bug quite evident. > > Eww. Yes, the act of resetting an elevated priority at the return > transition to userland would be a problem here. Well, the correct priority is set on return to userland, but it isn't acted on immediately, so the process effectively keeps its high kernel priority in user mode (until it is interrupted and the interrupt handler reschedules, or it gives up control). This is a broken if there is another process with a [much] higher priority, but probably a feature if the previous process has the same priority (since it improves interactive response). This interacts with some other scheduling bugs. > I know Bruce has a huge list of things he has changed here as well. I was > going for baby steps to make it usable again. I only have a long list of things related to this bug to change :-). I think the correct fix is to push down all priority adjustments as far as possible, and consider rescheduling (but rarely do it) whenever the priority is adjusted. E.g., processes that were sleeping at PPAUSE don't need that high priority after they wake up much more than when they went to sleep (then they usually have a user priority). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020708084010.J13539-100000>