[OpenAFS] console messages: "all buffers locked"
Wed, 28 Oct 2009 09:21:55 +0100
Simon Wilkinson schrieb:
> It wouldn't surprise me if some codepaths tie themselves in knots when
> DRead returns NULL - it's a rare enough occurence (and one which used to
> just panic, rather than printing the warning message) that it's probably
> not been widely examined. The two that never manage to free their
> lockers are interesting though - can you get cmdebug and alt-sysreq-t
> output from them while they're stuck? (If you could send that privately,
> or to RT, rather than the list)
> I hopefully did add a \n, too.
Alt-sysrq-t under way...
I believe we can exclude a "leak" under normal circumstances: I counted the
number of locked buffers and printed the results after every increase,
restarting every minute; as long as they stay below 50 things shrink and grow
> I suspect that ultimately, we're going to need to make the buffer
> structures dynamically allocated, with some kind of high and low
> watermark system. Each buffer takes up slightly more than 2k of memory -
> so having a large number permanently allocated is a little anti-social
> on platforms with limited memory.
The user space buffers.c already uses an indirection. Allocating a bigger
fixed size array just of buffer pointers which individually could be zero
until needed should be affordable, without affecting the performance
fine-tuning of the package.
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985 Fax: +41 22 767 7155