From owner-freebsd-arch Tue Dec 12 9: 8:58 2000 From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 09:08:55 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 5FC6237B6A4 for ; Tue, 12 Dec 2000 09:08:48 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBCH8ZE88691; Tue, 12 Dec 2000 09:08:36 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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, 12 Dec 2000 09:08:40 -0800 (PST) From: John Baldwin To: Seigo Tanimura Subject: Re: Even 1GB KVA is not enough, but we have no more space Cc: arch@FreeBSD.org, bright@wintelcom.net, dillon@earth.backplane.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12-Dec-00 Seigo Tanimura wrote: > On Sat, 09 Dec 2000 14:24:06 +0900, > Seigo Tanimura said: > > Seigo> And the saga continues. After regulating the size of struct swblock, > Seigo> ffs_vget() failed to allocalte a new vnode. At the time the PowerEdge > Seigo> failed, the kernel held around 197K vnodes, which is as large as > Seigo> 46MB. This time I reduced the size of kmem_map, the pool of malloc(9). > > Sorry, please forget this matter. The culprit truned out to be a race > condition of testing-and-setting ffs_inode_hash_lock in > ffs_vget(). Mutexifing the test-and-sleep-or-set and wakeup-reset > operations was enough to fix the problem. Now my kernel allocates up > to 316K vnodes on make buildworld and release, so malloc(9) pool of > 200MB is sufficient. (316K vnodes occupy about 90-100MB in kmem_map) > > > The updated patch is now at > > URI: http://people.FreeBSD.org/~tanimura/patches/kvmfix.diff > > which includes > > A. adaptation of swap metadata size, > B. rejection of swapon(2) upon failure of swap zone allocation, and > C. atomic test-and-set and reset of {ffs,ifs}_inode_hash_lock. > > I am going to commit this patch in about 6 hours from now. Mutexes look ok to me. One thing that you might do differently is this: mtx_enter(&foo); want_wakeup = foo_lock < 0; foo_lock = 0; mtx_exit(&foo); if (want_wakeup) wakeup(&foo_lock); The reason being that when you do the wakeup(), another CPU might start executing other kernel task immediately. The first thing it will do is block on the foo mutex and get switched out until you release the mutex after wakeup returns. Granted, there is a very small window here, and if it obfuscates the code too badly, it probably isn't worth the gain, however it is something to keep in mind. -- 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-arch" in the body of the message