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
as expected.
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.
Cheers, Rainer
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985 Fax: +41 22 767 7155
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
