Date: Tue, 1 May 2001 15:20:11 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jake Burkholder <jburkholder0829@home.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, Alfred Perlstein <bright@wintelcom.net>, smp@FreeBSD.ORG Subject: Re: that vm diff now makes it into single user mode. Message-ID: <Pine.BSF.4.21.0105011443590.32017-100000@besplex.bde.org> In-Reply-To: <20010501040903.5C10F22A5@k7.rchrd1.on.wave.home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 May 2001, Jake Burkholder wrote: > [bde wrote] > > On Mon, 30 Apr 2001, John Baldwin wrote: > > > Having the idle process hold locks that other threads block on can really start > > > wreaking havoc when you throw priority propagation into the mix. It would be > > > best to push the page zeroing off into a very low priority kernel thread or > > > something. > > > > Why would that do more than move the problem (if any)? Priority > > propagation should allow the low-priority idle process to become high > > prority so that it can release its locks as necessary just as well as > > it allows this for any other low-priority process. > > Because the idle process is special. It has low priority but is > never placed on a run queue like other processes. Usually what > happens is propogate_priority derefences a NULL pointer when it > tries to remove the idle proc from the run queue and place it on > a higher priority one. I think it shouldn't exist then. If it can't do much except loop, then it can be reduced to a loop like the old idle loop. The loop can't even have an APM call like some versions of the old idle loop, since APM might need a sleep mutex. > Using a normal low priority kernel thread should solve the problem. > However, I'm concerned that it would consume too much cpu time due > to hardclock not being to force a reschedule while it is running. > Interrupt threads would preempt it and allow other processes to run > when they "return", but asts would not happen due to it being in > kernel mode all the time. I suppose that the old idle loop would > have had the same effect. The old idle loop handled this by zeroing at most one page per iteration. A separate thread could limit itself similarly by giving up control if cnt.v_intr increases while one page is being zeroed. However, I think the watermarks make the efficiency issues moot if they (the watermarks) actually work. vm_page_zero_idle() (better: the idle loop itself) can just check the watermarks and wake up the process if there is enough to do. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0105011443590.32017-100000>