From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754085AbcFPL0P (ORCPT ); Thu, 16 Jun 2016 07:26:15 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:36460 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753850AbcFPL0J (ORCPT ); Thu, 16 Jun 2016 07:26:09 -0400 Date: Thu, 16 Jun 2016 13:26:06 +0200 From: Michal Hocko To: Dave Chinner Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Vlastimil Babka , Johannes Weiner , Rik van Riel , LKML Subject: Re: [RFC PATCH 2/2] xfs: map KM_MAYFAIL to __GFP_RETRY_HARD Message-ID: <20160616112606.GH6836@dhcp22.suse.cz> References: <1465212736-14637-1-git-send-email-mhocko@kernel.org> <1465212736-14637-3-git-send-email-mhocko@kernel.org> <20160616002302.GK12670@dastard> <20160616080355.GB6836@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160616080355.GB6836@dhcp22.suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 16-06-16 10:03:55, Michal Hocko wrote: > On Thu 16-06-16 10:23:02, Dave Chinner wrote: > > On Mon, Jun 06, 2016 at 01:32:16PM +0200, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > > > so it relied on the default page allocator behavior for the given set > > > of flags. This means that small allocations actually never failed. > > > > > > Now that we have __GFP_RETRY_HARD flags which works independently on the > > > allocation request size we can map KM_MAYFAIL to it. The allocator will > > > try as hard as it can to fulfill the request but fails eventually if > > > the progress cannot be made. > > > > > > Signed-off-by: Michal Hocko > > > --- > > > fs/xfs/kmem.h | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/fs/xfs/kmem.h b/fs/xfs/kmem.h > > > index 689f746224e7..34e6b062ce0e 100644 > > > --- a/fs/xfs/kmem.h > > > +++ b/fs/xfs/kmem.h > > > @@ -54,6 +54,9 @@ kmem_flags_convert(xfs_km_flags_t flags) > > > lflags &= ~__GFP_FS; > > > } > > > > > > + if (flags & KM_MAYFAIL) > > > + lflags |= __GFP_RETRY_HARD; > > > + > > > > I don't understand. KM_MAYFAIL means "caller handles > > allocation failure, so retry on failure is not required." To then > > map KM_MAYFAIL to a flag that implies the allocation will internally > > retry to try exceptionally hard to prevent failure seems wrong. > > The primary point, which I've tried to describe in the changelog, is > that the default allocator behavior is to retry endlessly for small > orders. You can override this by using __GFP_NORETRY which doesn't retry > at all and fails quite early. My understanding of KM_MAYFAIL is that > it can cope with allocation failures. The lack of __GFP_NORETRY made me > think that the failure should be prevented as much as possible. > __GFP_RETRY_HARD is semantically somwhere in the middle between > __GFP_NORETRY and __GFP_NOFAIL semantic independently on the allocation > size. > > Does that make more sense now? I would add the following explanation into the code: diff --git a/fs/xfs/kmem.h b/fs/xfs/kmem.h index 34e6b062ce0e..10708f065191 100644 --- a/fs/xfs/kmem.h +++ b/fs/xfs/kmem.h @@ -54,6 +54,13 @@ kmem_flags_convert(xfs_km_flags_t flags) lflags &= ~__GFP_FS; } + /* + * Default page/slab allocator behavior is to retry for ever + * for small allocations. We can override this behavior by using + * __GFP_RETRY_HARD which will tell the allocator to retry as long + * as it is feasible but rather fail than retry for ever for all + * request sizes. + */ if (flags & KM_MAYFAIL) lflags |= __GFP_RETRY_HARD; -- Michal Hocko SUSE Labs