Date: Sat, 6 Jun 2009 20:14:07 +0200 From: Nick Barkas <snb@freebsd.org> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: svn-src-head@freebsd.org, dwmalone@maths.tcd.ie, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r193375 - head/sys/ufs/ufs Message-ID: <20090606181405.GA2928@ebi.local> In-Reply-To: <20090603210652.GD3821@garage.freebsd.pl> References: <200906030944.n539iM2K045164@svn.freebsd.org> <20090603210652.GD3821@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 03, 2009 at 11:06:52PM +0200, Pawel Jakub Dawidek wrote: > On Wed, Jun 03, 2009 at 09:44:22AM +0000, Sean Nicholas Barkas wrote: > > Author: snb > > Date: Wed Jun 3 09:44:22 2009 > > New Revision: 193375 > > URL: http://svn.freebsd.org/changeset/base/193375 > > > > Log: > > Add vm_lowmem event handler for dirhash. This will cause dirhashes to be > > deleted when the system is low on memory. This ought to allow an increase to > > vfs.ufs.dirhash_maxmem on machines that have lots of memory, without > > degrading performance by having too much memory reserved for dirhash when > > other things need it. The default value for dirhash_maxmem is being kept at > > 2MB for now, though. > > > > This work was mostly done during the 2008 Google Summer of Code. > > > > Approved by: dwmalone (mentor), re > > MFC after: 3 months > [...] > > +static int > > +ufsdirhash_destroy(struct dirhash *dh) > > +{ > [...] > > + /* Remove it from the list and detach its memory. */ > > + TAILQ_REMOVE(&ufsdirhash_list, dh, dh_list); > [...] > > +static void > > +ufsdirhash_lowmem() > > +{ > [...] > > + /* > > + * Delete dirhashes not used for more than ufs_dirhashreclaimage > > + * seconds. If we can't get a lock on the dirhash, it will be skipped. > > + */ > > + for (dh = TAILQ_FIRST(&ufsdirhash_list); dh != NULL; dh = > > + TAILQ_NEXT(dh, dh_list)) { > > + if (!sx_try_xlock(&dh->dh_lock)) > > + continue; > > + if (time_second - dh->dh_lastused > ufs_dirhashreclaimage) > > + memfreed += ufsdirhash_destroy(dh); > > + /* Unlock if we didn't delete the dirhash */ > > + else > > + ufsdirhash_release(dh); > > + } > > + > > + /* > > + * If not enough memory was freed, keep deleting hashes from the head > > + * of the dirhash list. The ones closest to the head should be the > > + * oldest. > > + */ > > + for (dh = TAILQ_FIRST(&ufsdirhash_list); memfreed < memwanted && > > + dh !=NULL; dh = TAILQ_NEXT(dh, dh_list)) { > > + if (!sx_try_xlock(&dh->dh_lock)) > > + continue; > > + memfreed += ufsdirhash_destroy(dh); > > + } > > + DIRHASHLIST_UNLOCK(); > > +} > > I don't see how that works. If you remove dh from the tailq in > ufsdirhash_destroy(), you can't do 'dh = TAILQ_NEXT(dh, dh_list)' at the > end of the loop. > > You should use TAILQ_FOREACH_SAFE(3). In the second case you also need to > move this extra check into the loop, probably. Yes, I think you are right. Thanks for catching that. I think that, as written, both loops will only try to delete the first hash they can lock in ufsdirhash_list. I'll try to correct that. > In addition you drop DIRHASHLIST lock in ufsdirhash_destroy() during the > loop. Can't the tailq be modified from elsewhere? Or even from parallel > call to ufsdirhash_lowmem() (I don't think we serialize those)? The lock is held on the tailq while we are doing TAILQ_REMOVE(). It is only released for freeing data structures contained in dirhashes that have been removed from the tailq. I don't see how this would be a problem, but I certainly could be missing something. But, I don't really understand why the lock is dropped within ufsdirhash_destroy(), anyway. Perhaps it is not necessary to do so. I mostly just copied the code needed out of ufsdirhash_recycle() to write ufsdirhash_destroy(). ufsdirhash_recycle() I think could be concurrently called (by ufsdirhash_build()) previously, with the lock on ufsdirhash_list lock dropped in the same place, and I don't think this caused any problems. Nick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090606181405.GA2928>