Subject: Re: make vnodes freeable
To: YAMAMOTO Takashi <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/02/2003 18:29:39
On Thu, 3 Jul 2003, YAMAMOTO Takashi wrote:
> > > following patch is to make vnodes freeable.
> > > i.e. you can decrease kern.maxvnodes.
> > 1) Why do we need the new lists in struct namecache? (I'm not saying
> > there isn't a reason, I'm saying I don't see it :-) Freeing a vnode is the
> > exact same thing to the namecache as revoking it, which we do now. So why
> > do we need these new lists?
> because, after we free a vnode, a pointer to the vnode held by namecache
> becomes invalid. besides, i'd like to free stale namacaches soon as well as
> vnodes themselves.
I understand the invalidity of the namecache pointer.
My question is why is this not an issue now? As soon as we reclaim a
vnode, those pointers are JUST as invalid as they would be after a free.
Why is this not an issue with the current code?
> > 2) This patch won't do what I'd expect. If I reduce the number of vnodes,
> > I'd expect to get memory freed up. That won't really happen here. Yes, you
> > call pool_free(), but it won't free pages until the whole page is free.
> > i.e. until pool_free() has been called on all the vnodes in a given page.
> you mean pool_put()?
> > Granted, if you lower the number of vnodes enough, you will get some freed
> > pages.
> i think it's enough.
> > To really make it work right, we need to more-heavily poolify the vnode
> > free list. I'm not sure, though, if we can get the correct semantics (we
> > need to preserve the free list).
> what do you mean "heavily poolify"?
> do you mean, some mechanisms to reclaim pool items on the same page preferably?
> it might be good, but sounds like another story.
What I mean is that vnodes on the free list have been pool_put()'d, and we
add code to VOP_RECLAIM() during an object destruction. We also add code
to have a "pool_get_with_addr()" that pool_get's a given vnode.