netdev - Re: [PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc in skb_page_frag

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 08 Jan 2014 14:01:00 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Debabrata Banerjee <dbavatar@...il.com>
Cc:	"Michael S. Tsirkin" <mst@...hat.com>,
	Michael Dalton <mwdalton@...gle.com>,
	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jason Wang <jasowang@...hat.com>,
	virtualization@...ts.linux-foundation.org,
	Joshua Hunt <johunt@...mai.com>, jbaron@...mai.com
Subject: Re: [PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc
 in skb_page_frag_refill

On Wed, 2014-01-08 at 16:54 -0500, Debabrata Banerjee wrote:

> Actually I have more data on this:
> 

Could you please stop polluting this thread ?

> 1. __GFP_NORETRY really does help and should go into stable tree.
> 

Not at all. You are free to patch your kernel if you want.

It helps you workload, and breaks all others.

If compaction is never triggered, we'll never be able to get high order
pages, and performance goes back to what we had 2 years ago.

That discussion does not belong to this thread, again.

> 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 pressure from page_cache, and mm ends up constantly
> reclaiming and trying to keep another 1-2GB free on our systems (8GB
> phys ~4GB left for kernel, ~3GB optimally used for page_cache).
> 
> 4. I think perhaps using a kmem_cache allocation for this buffer is
> the right way to make this work. I am experimenting with a patch to do
> this.

Seriously... I think you missed whole point of having frag allocation on
pages, not kmem_cache.



--
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