[OpenAFS-devel] Re: [OpenAFS] 2.6 kernel support anytime soon?
Workarounds?
Jeffrey Hutzelman
jhutz@cmu.edu
Tue, 11 May 2004 12:09:26 -0400
On Tuesday, May 11, 2004 10:35:47 -0500 "Neulinger, Nathan" <nneul@umr.edu>
wrote:
>> I don't think that's a big deal. There's not currently any
>> benefit to
>> GC'ing PAG's, since they're just numbers in a namespace we
>> don't expect
>> ever to reuse. The tokens themselves will be GC'd once they
>> are expired
>> for some period of time, so the memory use is not an issue.
>
> Is the kernel "afs users" hash a hash of tokens or a hash of pags?
>
> If the hash is based on pags, then GC'ing most definately matters,
> especially on linux if you have a significant multi-user system that
> gets lots of pags - the behavior of the hash degrades very badly when it
> gets large to the point of causing 1-10 second kernel hangs periodically
> if it gets very large. We implemented our own external garbage
> collection with kdump and scanning of /proc which helped the problem
> tremendously.
The hash table maps a PAG number to a set of tokens.
Lots of PAGs aren't an issue; a PAG is just a number. Other than
incrementing the last-pag-assigned value, it consumes no resources
whatsoever.
Lots of PAGS with tokens are an issue, since they take up storage. Note
that the tokens don't necessarily go away just because there are no longer
any processes in that PAG -- there's no reference counting, since that
would require being able to track every case in which a process can be
created or destroyed. However, expired tokens will eventually be GC'd.
If you have a large multi-user machine with lots of turnover, it will help
a lot to make sure users unlog when they log out. Barring that, it will be
helpful to have a garbage collector which looks for "orphaned" tokens. In
fact, it's so useful that the cache manager contains code to do that, if
AFS_GCPAGS is defined (which it is on most platforms).
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA