linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: NeilBrown <neilb@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Theodore Ts'o <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	Michal Hocko <mhocko@suse.com>,
	Jesper Dangaard Brouer <jbrouer@redhat.com>,
	". Dave Chinner" <david@fromorbit.com>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH 1/6] MM: Support __GFP_NOFAIL in  alloc_pages_bulk_*() and improve doco
Date: Fri, 17 Sep 2021 15:42:33 +0100	[thread overview]
Message-ID: <20210917144233.GD3891@suse.de> (raw)
In-Reply-To: <163184741776.29351.3565418361661850328.stgit@noble.brown>

I'm top-posting to cc Jesper with full context of the patch. I don't
have a problem with this patch other than the Fixes: being a bit
marginal, I should have acked as Mel Gorman <mgorman@suse.de> and the
@gfp in the comment should have been @gfp_mask.

However, an assumption the API design made was that it should fail fast
if memory is not quickly available but have at least one page in the
array. I don't think the network use case cares about the situation where
the array is already populated but I'd like Jesper to have the opportunity
to think about it.  It's possible he would prefer it's explicit and the
check becomes
(!nr_populated || ((gfp_mask & __GFP_NOFAIL) && !nr_account)) to
state that __GFP_NOFAIL users are willing to take a potential latency
penalty if the array is already partially populated but !__GFP_NOFAIL
users would prefer fail-fast behaviour. I'm on the fence because while
I wrote the implementation, it was based on other peoples requirements.

On Fri, Sep 17, 2021 at 12:56:57PM +1000, NeilBrown wrote:
> When alloc_pages_bulk_array() is called on an array that is partially
> allocated, the level of effort to get a single page is less than when
> the array was completely unallocated.  This behaviour is inconsistent,
> but now fixed.  One effect if this is that __GFP_NOFAIL will not ensure
> at least one page is allocated.
> 
> Also clarify the expected success rate.  __alloc_pages_bulk() will
> allocated one page according to @gfp, and may allocate more if that can
> be done cheaply.  It is assumed that the caller values cheap allocation
> where possible and may decide to use what it has got, or to call again
> to get more.
> 
> Acked-by: Mel Gorman <mgorman@suse.com>
> Fixes: 0f87d9d30f21 ("mm/page_alloc: add an array-based interface to the bulk page allocator")
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
>  mm/page_alloc.c |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b37435c274cf..aa51016e49c5 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5191,6 +5191,11 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask, unsigned int order,
>   * is the maximum number of pages that will be stored in the array.
>   *
>   * Returns the number of pages on the list or array.
> + *
> + * At least one page will be allocated if that is possible while
> + * remaining consistent with @gfp.  Extra pages up to the requested
> + * total will be allocated opportunistically when doing so is
> + * significantly cheaper than having the caller repeat the request.
>   */
>  unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
>  			nodemask_t *nodemask, int nr_pages,
> @@ -5292,7 +5297,7 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
>  								pcp, pcp_list);
>  		if (unlikely(!page)) {
>  			/* Try and get at least one page */
> -			if (!nr_populated)
> +			if (!nr_account)
>  				goto failed_irq;
>  			break;
>  		}
> 
> 

  reply	other threads:[~2021-09-17 14:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17  2:56 [PATCH 0/6 v2] congestion_wait() and GFP_NOFAIL NeilBrown
2021-09-17  2:56 ` [PATCH 6/6] XFS: remove congestion_wait() loop from xfs_buf_alloc_pages() NeilBrown
2021-09-17  2:56 ` [PATCH 5/6] XFS: remove congestion_wait() loop from kmem_alloc() NeilBrown
2021-09-17 21:45   ` Dave Chinner
2021-09-17  2:56 ` [PATCH 1/6] MM: Support __GFP_NOFAIL in alloc_pages_bulk_*() and improve doco NeilBrown
2021-09-17 14:42   ` Mel Gorman [this message]
2021-09-20 23:48     ` NeilBrown
2021-10-05  9:16     ` Vlastimil Babka
2021-09-17  2:56 ` [PATCH 3/6] EXT4: Remove ENOMEM/congestion_wait() loops NeilBrown
2021-09-17  2:56 ` [PATCH 4/6] EXT4: remove congestion_wait from ext4_bio_write_page, and simplify NeilBrown
2021-09-17  2:56 ` [PATCH 2/6] MM: improve documentation for __GFP_NOFAIL NeilBrown
2021-10-05  9:20   ` Vlastimil Babka
2021-10-05 11:09     ` Michal Hocko
2021-10-05 12:27       ` Vlastimil Babka
2021-10-06 23:14         ` Dave Chinner
2021-10-07 10:07           ` Michal Hocko
2021-10-07 23:15             ` NeilBrown
2021-10-08  7:48               ` Michal Hocko
2021-10-08 22:36                 ` Dave Chinner
2021-10-11 11:57                   ` Michal Hocko
2021-10-11 21:49                     ` NeilBrown
2021-10-18 10:23                       ` Michal Hocko
2021-10-19  4:32                         ` NeilBrown
2021-10-19 13:59                           ` Michal Hocko
2021-10-22  0:09                             ` NeilBrown
2021-10-13  2:32                     ` Dave Chinner
2021-10-13  8:26                       ` Michal Hocko
2021-10-14 11:32                         ` David Sterba
2021-10-14 11:46                           ` Michal Hocko

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=20210917144233.GD3891@suse.de \
    --to=mgorman@suse.de \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=jbrouer@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=neilb@suse.de \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).