From owner-freebsd-smp Tue May 1 7:49:19 2001 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 44B6F37B424 for ; Tue, 1 May 2001 07:49:16 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f41En1K20514; Tue, 1 May 2001 07:49:01 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f41EkIN47396; Tue, 1 May 2001 07:46:18 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 01 May 2001 07:46:18 -0700 (PDT) Organization: BSD, Inc. From: John Baldwin To: Bruce Evans Subject: Re: that vm diff now makes it into single user mode. Cc: Jake Burkholder , smp@FreeBSD.ORG, Alfred Perlstein Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 01-May-01 Bruce Evans wrote: > 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. That doesn't work because idle processes aren't on the run queue. They are simply a hold context chosen when there is no context to move to. Thus, priority propagation doesn't affect them since by this principle, every other process has higher priority than the idle process, regardless of the actual value of p_pri. > Bruce -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message