Messages in this thread | | | Date | Wed, 25 Aug 2004 12:20:48 +1000 | From | Nick Piggin <> | Subject | Re: page allocation failure & sk98lin |
| |
Serban Simu wrote: > Thank you, Nick. Just wanted to mention that while I understand that we > recover from this allocation failure (and also I don't mind the stack > printouts), about 20% of my incoming network traffic (600-700 Mbps) > seems to be dropped in the process.
Yeah that is expected - so I guess it isn't exactly 'harmless' if performance is critical.
> Does the memory manager have to > spend a considerable amount of time to recover? > > I will have a look at the -mm fixes, thanks for the idea. >
The relevant patch is this one which is now merged into 2.6.
http://linux.bkbits.net:8080/linux-2.5/cset@412b8828ClkE2ZwNwGQ02aYoMwb7-A?nav=index.html|ChangeSet@-1d
It would be nice if you can test that. It will give GFP_ATOMIC allocators a larger buffer between starting memory reclaim, and failing their allocations.
However if it is a production system and you can't test patches, Marcelo pointed out that you should be able to work around the problem by increasing /proc/sys/vm/min_free_kbytes. Then maybe you could try 2.6.9 with min_free_kbytes back to its default setting :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |