Date: Tue, 01 May 2001 00:09:03 -0400 From: Jake Burkholder <jburkholder0829@home.com> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@FreeBSD.ORG>, Alfred Perlstein <bright@wintelcom.net>, smp@FreeBSD.ORG, Jake Burkholder <jburkholder0829@home.com> Subject: Re: that vm diff now makes it into single user mode. Message-ID: <20010501040903.5C10F22A5@k7.rchrd1.on.wave.home.com> In-Reply-To: Message from Bruce Evans <bde@zeta.org.au> of "Tue, 01 May 2001 12:57:44 %2B1000." <Pine.BSF.4.21.0105011221040.31299-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, 30 Apr 2001, John Baldwin wrote: > > > On 29-Apr-01 Alfred Perlstein wrote: > > > * Jake Burkholder <jburkholder0829@home.com> [010428 23:10] wrote: > > >> > > >> i386/i386/vm_machdep.c: > > >> > > >> the mtx_trylock in vm_page_zero_idle is unnecessary, the lock is > > >> already held. This whole thing needs to be non-blocking if its > > >> going to be called from the idle loop, but I'm not sure that > > >> that's still possible. Its currently commented out. > > > > > > Ok, should be fixed. I guess we now know where it could have been > > > useful to be able to spin on a sleeplock, ie not worry about > > > idle getting stuck on a runqueue/sleepqueue. > > > > 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. 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. Jake 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?20010501040903.5C10F22A5>