On Wed, 3 Dec 1997 13:31:32 +0100 (MET), Ingo Molnar
<mingo@pc7537.hil.siemens.at> said:
> running the memory leak tracer i noticed that we never free inodes.
> Ok, this is by design, but not that we do not free them, we also seem to
> leak away inodes slowly, not respecting the NR_INODE limit.
I've had this mail at the back of my mind for a while as I've been
looking through another few possible races in inode.c. Coming back to
the original message, however, ...
> After 1.5 days of uptime, here is the 'allocation flux' of inode.c:118:
...
> This log means that since the detector has been started, 166 new pages
> were allocated, thats a total of 284 pages. Those numbers are 'new
> allocations' between ~2 minutes checkpoints.
> These are 1.1MB unswappable, kernel-resident pages, on a 32M RAM light
> desktop box. I understand that we are actually limiting inode allocation,
> but isnt 1.1MB a bit too much? And we never seem to free those pages, by
> design.
> NR_INODE is the default 3072, and inodes are 128 bytes, so we should have
> stopped at about 393K? Is this correct and this is really a leak?
Ext2 inodes are 128 bytes on disk. Inodes in memory are larger: they
contain a union of all the individual filesystems' inode structures,
plus the kernel's VFS inode tracking bits. In fact, inodes in memory
are a _lot_ larger --- 264 bytes, typically, giving 15 to a page.
That's a total of 204 pages, 816kB, for a maximum 3072 inodes.
I can't see how you could possibly get 284 pages allocated with
max_inodes == 3072. Looking at your trace of inode allocations:
> After 1.5 days of uptime, here is the 'allocation flux' of inode.c:118:
>
> inode.c:118: 26 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 1 0 0
> ...
> DELTA: 166
Ah. 284 == 118 + 166, but I suspect that "inode.c:118" doesn't actually
indicate that we started off with 118 pages --- it happens that in
inode.c, the allocation of pages for inodes occurs on line 118, so I
think you haven't actually exceeded max_inodes here.
The interesting thing from your trace is a single burst where we
allocated 110 pages to inodes in a single trace period, and that may
well indicate something we need to fix. The trouble is that inodes are
used as anchors for the page cache, and being more aggressive in reaping
and reusing inodes may well impact caching performance as a result.
--Stephen