From owner-freebsd-smp Mon Apr 30 21: 6:27 2001 Delivered-To: freebsd-smp@freebsd.org Received: from cr66388-a.rchrd1.on.wave.home.com (cr66388-a.rchrd1.on.wave.home.com [24.114.165.24]) by hub.freebsd.org (Postfix) with ESMTP id 0A40237B422; Mon, 30 Apr 2001 21:06:23 -0700 (PDT) (envelope-from jburkholder0829@home.com) Received: from k7.rchrd1.on.wave.home.com (k7.rchrd1.on.wave.home.com [10.0.0.253]) by cr66388-a.rchrd1.on.wave.home.com (Postfix) with ESMTP id 3336B196; Tue, 1 May 2001 00:06:33 -0400 (EDT) Received: from k7.rchrd1.on.wave.home.com (localhost [127.0.0.1]) by k7.rchrd1.on.wave.home.com (Postfix) with ESMTP id 5C10F22A5; Tue, 1 May 2001 00:09:03 -0400 (EDT) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans Cc: John Baldwin , Alfred Perlstein , smp@FreeBSD.ORG, Jake Burkholder Subject: Re: that vm diff now makes it into single user mode. In-Reply-To: Message from Bruce Evans of "Tue, 01 May 2001 12:57:44 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 00:09:03 -0400 From: Jake Burkholder Message-Id: <20010501040903.5C10F22A5@k7.rchrd1.on.wave.home.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Mon, 30 Apr 2001, John Baldwin wrote: > > > On 29-Apr-01 Alfred Perlstein wrote: > > > * Jake Burkholder [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