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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
