Displaying 3 results from an estimated 3 matches for "gfp_nokswapd".
2014 Jan 08
2
[PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill
On Wed, 2014-01-08 at 21:18 +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 08, 2014 at 10:26:03AM -0800, Eric Dumazet wrote:
> > On Wed, 2014-01-08 at 20:08 +0200, Michael S. Tsirkin wrote:
> >
> > > Eric said we also need a patch to add __GFP_NORETRY, right?
> > > Probably before this one in series.
> >
> > Nope, this __GFP_NORETRY has nothing to do
2014 Jan 08
2
[PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill
On Wed, 2014-01-08 at 21:18 +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 08, 2014 at 10:26:03AM -0800, Eric Dumazet wrote:
> > On Wed, 2014-01-08 at 20:08 +0200, Michael S. Tsirkin wrote:
> >
> > > Eric said we also need a patch to add __GFP_NORETRY, right?
> > > Probably before this one in series.
> >
> > Nope, this __GFP_NORETRY has nothing to do
2014 Jan 08
0
[PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...s not work.
>
> If these people care, they should contact mm guys, eventually.
>
> Really this is an issue that has nothing to do with this patch set.
>
Actually I have more data on this:
1. __GFP_NORETRY really does help and should go into stable tree.
2. You may want to consider GFP_NOKSWAPD, because even in the
GFP_ATOMIC case you are waking up kswapd to do reclaims on a
continuous basis even when you don't enter direct reclaim.
3. mlocking memory had very little to do with it, that was a
red-herring. I tested out the problem scenario with no mlocks. You
simply need memory pressu...