Re: less aggressive contigmalloc ?

On 08/27/2012 06:39, Luigi Rizzo wrote:
> On Mon, Aug 27, 2012 at 02:42:28AM -0500, Alan Cox wrote:
> ...
>>> this is dmesg when I add kdb_backtrace()  at the start of vm_pageout_oom()
>>> The '... netmap_finalize_obj_allocator... are from my calls to
>>> contigmalloc, each one doing one-page allocations.
>> These calls are made with M_WAITOK?
> no they are with M_NOWAIT:
>
> 	...
> 	clust = contigmalloc(p->_clustsize, M_NETMAP, M_NOWAIT | M_ZERO,
> 	    0, -1UL, PAGE_SIZE, 0);
> 	...
>
> p->_clustsize is 4096 in this particular set of calls.

If M_NOWAIT is passed to contigmalloc(), then there is no call path by 
which contigmalloc() or any function that it calls would call 
vm_pageout_oom().  contigmalloc() may, however, wake the page daemon if 
the free page queues become sufficiently depleted.

>>> I get 7-8 'KDB: stack backtrace' blocks, then allocations
>>> restart successfully, then more failures...
>>> The reference to fork_exit() does not seem right, because i am
>>> in a block where i call contigmalloc, so the caller of
>>> vm_pageout_grow_cache() should be kmem_alloc_contig().
>> Try this instead.  At the start of vm_pageout_oom(), print the value of
>> its parameter "shortage".  That will uniquely identify the caller.
> it says "shortage is 1" which means that the call is from vm_pageout().

Yes.  I'm afraid that you're simply running short of memory.  There's 
nothing particular to contigmalloc() happening here.  Anything that 
allocated and wired the same amount of physical memory would have the 
same effect.

However, if you're confident that the machine really has sufficient 
memory to support what you're trying to run, then you could tinker with 
the page daemon's targets for free pages.

Alan