Date: Fri, 08 Jun 2001 11:15:42 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: tlambert2@mindspring.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UFS large directory performance Message-ID: <200106081115.aa43142@salmon.maths.tcd.ie> In-Reply-To: Your message of "Thu, 07 Jun 2001 23:52:50 PDT." <3B207642.A7C7E7C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3B207642.A7C7E7C@mindspring.com>, Terry Lambert writes: > >Use a chain allocator. I would suggest using the zone >allocator, but it has some fundamental problems that I >don't think are really resolvable without a rewrite. Heh, maybe, but I'm not sure I want to write a new allocator for this :-) Based on Matt's suggestions, I implemented the 2-level approach. It currently uses 256 slots per second-level block; these 1k blocks are allocated using zalloc(). The variable-length first-level arrays are still allocated with malloc, but these don't grow to more than a few kb in size unless the directories are enormous. There's now a simple LRU list of dirhash structures that have memory attached, and a new function ufsdirhash_recycle() that will free up memory when the sysctl limit is reached. Adding this required some locking, but the problematic inode locking is avoided by leaving the dirhash structure attached to the inode when its hash array is freed. An updated patch is available at http://www.maths.tcd.ie/~iedowse/FreeBSD/dirhash.diff3 I haven't had a chance to do more than a minimal amount of testing, so there may be many issues remaining. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200106081115.aa43142>