Re: BUG: Slowdown on 3000 socket-machines tracked down

[Andi Kleen]

Andrew Morton <akpm@xxxxxxxx> writes:

> Christian Schmid <webmaster@xxxxxxxxxxxxxx> wrote:
>>
>>  > So, maybe a VM problem?  That would be a good place to focus since
>>  > I think we can be fairly certain it isn't a problem in just the
>>  > networking code.  Otherwise, my tests would show lower bandwidth.
>> 
>>  Thanks to your tests I am really sure that its no network-code problem anymore. But what I THINK it 
>>  is: The network is allocating buffers dynamically and if the vm doesnt provide that buffers fast 
>>  enough, it locks as well.
>
> Did anyone have a 100-liner which demonstrates this problem?
>
> The output of `vmstat 1' when the thing starts happening would be interesting.

If he had a lot of RX traffic (it is hard to figure out because his
bug reports are more or less useless and mostly consists of rants):
The packets are allocated with GFP_ATOMIC and a lot of traffic
overwhelms the free memory.

Some drivers work around this by doing the RX ring refill in process
context (easier with NAPI), but not all do.

In general to solve it one has to increase /proc/sys/vm/freepages
a lot.

It would be nice though if the VM tuned itself dynamically to a lot
of GFP_ATOMIC requests. And maybe if GFP_ATOMIC was a bit more aggressive
and did some simple minded reclaiming that would be helpful too.
e.g. there could be a "easy to free" list in the VM for clean pages
where freeing is simple enough that it could be made interrupt safe.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/