lkml.org 
[lkml]   [2004]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.297 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site