Date: Sat, 02 Jun 2001 12:07:03 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Matt Dillon <dillon@earth.backplane.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UFS large directory performance Message-ID: <200106021207.aa78407@salmon.maths.tcd.ie> In-Reply-To: Your message of "Fri, 01 Jun 2001 10:52:40 PDT." <200106011752.f51HqeS85237@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200106011752.f51HqeS85237@earth.backplane.com>, Matt Dillon writes: > What are your commit plans? It looks extremely well contained, > it could be committed to -current and then -stable a few days later > without any destabilizing impact at all for when the option isn't > specified. ... > The only potential problem I see here is that you could end up > seriously fragmenting the malloc pool you are using to allocate the > slot arrays. And, of course, the two issues you brought up in > regards to regularing memory use. Thanks for the comments :-) Yes, malloc pool fragmentation is a problem. I think that it can be addressed to some extent by using a 2-level system (an array of pointers to fixed-size arrays) instead of a single large array, but I'm open to any better suggestions. If the second-level array size was fixed at around 4k, that would keep the variable-length first-level array small enough not to cause too many fragmentation issues. The per-DIRBLKSIZ free space summary array is probably relatively okay as it is now. The other main issue, that of discarding old hashes when the memory limit is reached, may be quite tricky to resolve. Any approach based on doing this from ufsdirhash_build() is likely to become a locking nightmare. My original idea was to have ufsdirhash_build() walk a list of other inodes with hashes attached and free them if possible, but that would involve locking the other inode, so things could get messy. 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? <200106021207.aa78407>