All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Debabrata Banerjee <dbavatar@gmail.com>, Chris Mason <clm@fb.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>, Shaohua Li <shli@fb.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	Kernel-team@fb.com, Eric Dumazet <edumazet@google.com>,
	David Rientjes <rientjes@google.com>,
	linux-mm@kvack.org, Joshua Hunt <johunt@akamai.com>,
	"Banerjee, Debabrata" <dbanerje@akamai.com>
Subject: Re: [RFC] net: use atomic allocation for order-3 page allocation
Date: Fri, 12 Jun 2015 11:25:30 +0200	[thread overview]
Message-ID: <557AA58A.2060207@suse.cz> (raw)
In-Reply-To: <CAATkVEw93KaUQuNJY9hxA+q2dxPb2AAxicojkjDfXDZU5VGxtg@mail.gmail.com>

On 06/11/2015 11:35 PM, Debabrata Banerjee wrote:
> There is no "background" it doesn't matter if this activity happens
> synchronously or asynchronously, unless you're sensitive to the
> latency on that single operation. If you're driving all your cpu's and
> memory hard then this is work that still takes resources. If there's a
> kernel thread with compaction running, then obviously your process is
> not.

Well that of course depends on the CPU utilization of "your process".

> Your patch should help in that not every atomic allocation failure
> should mean yet another run at compaction/reclaim.

If you don't want to wake up kswapd, add also __GFP_NO_KSWAPD flag. 
Additionally, gfp_to_alloc_flags() will stop treating such allocation as 
atomic - it allows atomic allocations to bypass cpusets and lowers the 
watermark by 1/4 (unless there's also __GFP_NOMEMALLOC). It might 
actually make sense to add __GFP_NO_KSWAPD for an allocation like this 
one that has a simple order-0 fallback.

Vlastimil


> -Deb
>
> On Thu, Jun 11, 2015 at 5:16 PM, Chris Mason <clm@fb.com> wrote:
>
>> networking is asking for 32KB, and the MM layer is doing what it can to
>> provide it.  Are the gains from getting 32KB contig bigger than the cost
>> of moving pages around if the MM has to actually go into compaction?
>> Should we start disk IO to give back 32KB contig?
>>
>> I think we want to tell the MM to compact in the background and give
>> networking 32KB if it happens to have it available.  If not, fall back
>> to smaller allocations without doing anything expensive.
>>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2015-06-12  9:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-11 20:24 [RFC] net: use atomic allocation for order-3 page allocation Shaohua Li
2015-06-11 22:27 ` [RFC v2] " Shaohua Li
2015-06-11 20:48 ` [RFC] " Eric Dumazet
2015-06-11 20:48   ` Eric Dumazet
2015-06-11 21:16   ` Chris Mason
2015-06-11 21:16     ` Chris Mason
2015-06-11 21:22     ` Eric Dumazet
2015-06-11 21:45       ` Shaohua Li
2015-06-11 21:45         ` Shaohua Li
2015-06-11 21:56         ` Eric Dumazet
2015-06-11 22:01           ` Shaohua Li
2015-06-11 22:01             ` Shaohua Li
2015-06-11 22:18       ` Chris Mason
2015-06-11 22:18         ` Chris Mason
2015-06-11 22:55         ` Eric Dumazet
2015-06-11 21:35     ` Debabrata Banerjee
2015-06-11 22:18       ` David Miller
2015-06-12  9:25       ` Vlastimil Babka [this message]
2015-06-11 21:25   ` Debabrata Banerjee
2015-06-11 21:28     ` Debabrata Banerjee
2015-06-12  9:34       ` Vlastimil Babka
2015-06-11 22:53 ` [RFC v2] " Eric Dumazet
2015-06-11 23:32   ` Shaohua Li
2015-06-11 23:32     ` Shaohua Li
2015-06-11 23:38     ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=557AA58A.2060207@suse.cz \
    --to=vbabka@suse.cz \
    --cc=Kernel-team@fb.com \
    --cc=clm@fb.com \
    --cc=davem@davemloft.net \
    --cc=dbanerje@akamai.com \
    --cc=dbavatar@gmail.com \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=johunt@akamai.com \
    --cc=linux-mm@kvack.org \
    --cc=netdev@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=shli@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.