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()?

Yes, sorry.

> > 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.

Take care,

Bill