Re: hammer-inodes: malloc limit exceeded

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:1. don't we need M_LOOPOK flag, which tells kmalloc() to wait until
:   the sum of ks_memuse[] becomes lower than ks_limit?  of course
:   only when !M_NULLOK && M_WAITOK.
:   struct hammer_inode is fairly small in size, so there could be
:   a good chance that a couple of them gets reclaimed after a while.

    No, because there is no guarantee that the caller won't deadlock.
    The bug is that the subsystem (HAMMER in this case) didn't control
    the allocations it was making.

:2. I know ks_loosememuse is not MP synchronized, but ks_memuse[] is
:   summed up without any locks, either.  couldn't there be a race?

    ks_loosememuse can be very wrong.  Summing up ks_memuse[] will
    give a correct result and while races can occur the difference
    will only be the difference due to the race, not some potentially
    wildly incorrect value.

:3. shouldn't the conditionals be
:   while (type->ks_loosememuse + size >= type->ks_limit) {
:      ...
:      if (ttl + size >= type->ks_limit) ...
:
:   to catch the situation earlier?
:
:Thanks in advance.

    I don't think this will help.  Subsystems have to control their
    memory use.  The kernel can't really save them.  HAMMER has an
    issue where it can allocate a virtually unlimited number of
    hammer_inode structures.  I have lots of code in there to try
    to slow it down when it gets bloated but clearly some cases are
    getting through and still causing the allocations to spiral out
    of control.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>