Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2000 09:08:40 -0800 (PST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
Cc:        arch@FreeBSD.org, bright@wintelcom.net, dillon@earth.backplane.com
Subject:   Re: Even 1GB KVA is not enough, but we have no more space
Message-ID:  <XFMail.001212090840.jhb@FreeBSD.org>
In-Reply-To: <vmd7ey8hdr.wl@rina.r.dl.itc.u-tokyo.ac.jp>

next in thread | previous in thread | raw e-mail | index | archive | help

On 12-Dec-00 Seigo Tanimura wrote:
> On Sat, 09 Dec 2000 14:24:06 +0900,
>   Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> 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 <jhb@FreeBSD.org> -- 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001212090840.jhb>