From owner-freebsd-current Thu Dec 20 12:16:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 7AB4E37B41A for ; Thu, 20 Dec 2001 12:16:25 -0800 (PST) Received: (qmail 22249 invoked from network); 20 Dec 2001 20:16:25 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 20:16:25 -0000 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: <20011220112415.B8230@iguana.aciri.org> Date: Thu, 20 Dec 2001 12:16:03 -0800 (PST) From: John Baldwin To: Luigi Rizzo Subject: Re: vm_zeropage priority problems. Cc: current@freebsd.org, Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 20-Dec-01 Luigi Rizzo wrote: > On Thu, Dec 20, 2001 at 11:13:27AM -0800, Peter Wemm wrote: > ... >> Excellent catch! This particular problem was one of the main reasons >> why this is still defaulting to 'off'. I have a couple of other changes >> to it pending commit to fix some of Bruce's complaints, but I hadn't >> noticed the cause of this. >> >> Part of the problem is that tsleep temporarily elevates the priority for >> wakeup, and it is normally returned back to "normal" level when the process >> returns to userland (see the *_userpri stuff). > > ah, ok, kernel threads never return to userland... > > so, i presume one should also make sure that after the process is > scheduled, the priority is restored to the 'native' level; this > should also solve the problem with the priority propagation mechanism > (though... I have the feeling that if you have nested locks, this > cannot scale...) Priority propagation will already handle things ok. We drop to pri_native after we drop a lock (although if we still hold a contested lock we bump our priority to the min(nativepri, highest priority of threads on contested locks we hold and drop to nativepri after dropping the last contested lock). However, kthreads should tsleep() with their current priority, not PPAUSE. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message