Re: [RFC][PATCH 0/3] beat kswapd with the proverbial clue-bat

[Nick Piggin]

Anton Blanchard wrote:
> > There have been few reports, and I believe that networking is getting
> > changed to reduce the amount of GFP_ATOMIC higher-order allocation
> > attempts.
>
>
> FYI I seem to remember issues on loopback due to its large MTU. Also the

Yeah I had seen a few, surprisingly few though. Sorry I'm a bit clueless
about networking - I suppose there is a good reason for the 16K MTU? My
first thought might be that a 4K one could be better on CPU cache as well
as lighter on the mm. I know the networking guys know what they're doing
though...

> printk_ratelimit stuff first appeared because the e1000 was spewing so
> many higher order page allocation failures on some boxes.
>
> But yes, the e1000 guys were going to look into multiple buffer mode so
> they dont need a high order allocation.

Well let me be the first to say I don't want to stop that from happening.

With regard to getting this patchset tested, I might see if I can hunt
down another e1000 and give it a try at the end of the week. If anyone
would like to beat me to it, just let me know and I'll send out a new
set of patches with those couple of required fixes.
-
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/