netdev - Re: [RFC] net: use atomic allocation for order-3 page allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <557AA58A.2060207@suse.cz>
Date:	Fri, 12 Jun 2015 11:25:30 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Debabrata Banerjee <dbavatar@...il.com>, Chris Mason <clm@...com>
CC:	Eric Dumazet <eric.dumazet@...il.com>, Shaohua Li <shli@...com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>, Kernel-team@...com,
	Eric Dumazet <edumazet@...gle.com>,
	David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
	Joshua Hunt <johunt@...mai.com>,
	"Banerjee, Debabrata" <dbanerje@...mai.com>
Subject: Re: [RFC] net: use atomic allocation for order-3 page allocation

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@...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@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>
>

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html