From owner-freebsd-smp Mon Apr 30 22:21:26 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 823AB37B422; Mon, 30 Apr 2001 22:21:22 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA25438; Tue, 1 May 2001 15:21:17 +1000 Date: Tue, 1 May 2001 15:20:11 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Jake Burkholder Cc: John Baldwin , Alfred Perlstein , smp@FreeBSD.ORG Subject: Re: that vm diff now makes it into single user mode. In-Reply-To: <20010501040903.5C10F22A5@k7.rchrd1.on.wave.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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