From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 07:43:18 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A67016A4CE for ; Thu, 3 Mar 2005 07:43:18 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id D506343D55 for ; Thu, 3 Mar 2005 07:43:17 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j237ghC4014878 for ; Thu, 3 Mar 2005 02:42:43 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j237ggmU014877 for arch@FreeBSD.ORG; Thu, 3 Mar 2005 02:42:42 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 3 Mar 2005 02:42:42 -0500 From: David Schultz To: arch@FreeBSD.ORG Message-ID: <20050303074242.GA14699@VARK.MIT.EDU> Mail-Followup-To: arch@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 07:43:18 -0000 Any objections to the idea of removing the feature of swapping out kernel stacks? Unlike disabling UAREA swapping, this has the small downside that it wastes 16K (give or take a power of 2) of wired memory per kernel thread that we would otherwise have swapped out. However, this disadvantage is probably negligible by today's standards, and there are several advantages: 1. David Xu found that some kernel code stores externally-accessible data structures on the stack, then goes to sleep and allows the stack to become swappable. This can result in a kernel panic. 2. We don't know how many instances of the above problem there are. Selectively disabling swapping for the right threads at the right times would decrease maintainability. 3. Thread stack swapping doesn't work very well anymore anyway. KSE introduced the idea that a process could have multiple kernel threads and hence multiple kernel stacks, but the swapper was not taught about this very well. All the threads in a process get swapped out at the same time, and this only happens if all the threads happen to be swappable at the same time. 4. The code isn't well maintained. That's not to say that it doesn't work, but it's conceivable that changes in locking elsewhere might introduce new bugs. What if swapout races with exit() while the latter is trying to kill off the threads in the process, for instance? If there were a bug, it could be very difficult to reproduce and track down. At least for now, I would retain the swapper daemon and its medium-term scheduling feature. (That is, under high load, it could mark some processes as unrunnable, thereby reducing contention and allowing their user space pages to be paged out.) This feature does not add much complexity to other parts of the kernel. If it turns out not to be very useful by itself, it can be removed later, but I'm not as zealous with the axe as phk. ;-)