Re: [PATCH] Improve Atheros ethernet driver not to do order 4 GFP_ATOMIC allocation

From: Chris Snook <chris.snook@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: David Miller <davem@davemloft.net>,
	pavel@ucw.cz, akpm@osdl.org, linux-kernel@vger.kernel.org,
	jcliburn@gmail.com, netdev@vger.kernel.org, rjw@rjwysocki.net,
	linux-mm@kvack.org, nic-devel@qualcomm.com, ronangeles@gmail.com,
	ebiederm@xmission.com
Subject: Re: [PATCH] Improve Atheros ethernet driver not to do order 4 GFP_ATOMIC allocation
Date: Thu, 03 Dec 2015 19:26:01 +0000	[thread overview]
Message-ID: <CAMXMK6v3i0djY2kW4OmJPvc5CuYFu8WeYeKa=Z0WSvk48wa6Rg@mail.gmail.com> (raw)
In-Reply-To: <20151203081646.GB9264@dhcp22.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

On Thu, Dec 3, 2015 at 12:16 AM Michal Hocko <mhocko@kernel.org> wrote:

> On Wed 02-12-15 22:43:31, Chris Snook wrote:
> > On Tue, Dec 1, 2015 at 12:35 PM David Miller <davem@davemloft.net>
> wrote:
> >
> > > From: Michal Hocko <mhocko@kernel.org>
> > > Date: Mon, 30 Nov 2015 14:21:29 +0100
> > >
> > > > On Sat 28-11-15 15:51:13, Pavel Machek wrote:
> > > >>
> > > >> atl1c driver is doing order-4 allocation with GFP_ATOMIC
> > > >> priority. That often breaks  networking after resume. Switch to
> > > >> GFP_KERNEL. Still not ideal, but should be significantly better.
> > > >
> > > > It is not clear why GFP_KERNEL can replace GFP_ATOMIC safely neither
> > > > from the changelog nor from the patch context.
> > >
> > > Earlier in the function we do a GFP_KERNEL kmalloc so:
> > >
> > > ¯\_(ツ)_/¯
> > >
> > > It should be fine.
> > >
> >
> > AFAICT, the people who benefit from GFP_ATOMIC are the people running all
> > their storage over NFS/iSCSI who are suspending their machines while
> > they're so busy they don't have any clean order 4 pagecache to drop, and
> > want the machine to panic rather than hang.
>
> Why would GFP_KERNEL order-4 allocation hang? It will fail if there are
> not >=4 order pages available even after reclaim and/or compaction.
> GFP_ATOMIC allocations should be used only when an access to memory
> reserves is really required. If the allocation just doesn't want to
> invoke direct reclaim then GFP_NOWAIT is a more suitable alternative.
>

The *machine* may hang if you can't bring back the interface that's
required to access the storage. It's a ridiculous use case, as Pavel noted.
I only pointed it out to note that there exists a rationale for GFP_ATOMIC.
It just isn't nearly as good as the rationale for using GFP_KERNEL.

-- Chris

[-- Attachment #2: Type: text/html, Size: 2478 bytes --]