linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Suren Baghdasaryan <surenb@google.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Christoph Lameter <cl@linux.com>,
	 David Rientjes <rientjes@google.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	 Harry Yoo <harry.yoo@oracle.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	rcu@vger.kernel.org,  maple-tree@lists.infradead.org
Subject: Re: [PATCH RFC v3 4/8] slab: sheaf prefilling for guaranteed allocations
Date: Wed, 23 Apr 2025 10:13:53 -0700	[thread overview]
Message-ID: <CAJuCfpHV7kewvi9kghPAE_JGCBchDDWxe0_LP8_2QkpQePWyDw@mail.gmail.com> (raw)
In-Reply-To: <7c4fe3af-a38b-4d40-9824-2935b46e1ecd@suse.cz>

On Wed, Apr 23, 2025 at 6:06 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 4/10/25 22:47, Suren Baghdasaryan wrote:
> >> +/*
> >> + * refill a sheaf previously returned by kmem_cache_prefill_sheaf to at least
> >> + * the given size
> >> + *
> >> + * the sheaf might be replaced by a new one when requesting more than
> >> + * s->sheaf_capacity objects if such replacement is necessary, but the refill
> >> + * fails (returning -ENOMEM), the existing sheaf is left intact
> >> + *
> >> + * In practice we always refill to full sheaf's capacity.
> >> + */
> >> +int kmem_cache_refill_sheaf(struct kmem_cache *s, gfp_t gfp,
> >> +                           struct slab_sheaf **sheafp, unsigned int size)
> >
> > nit: Would returning a refilled sheaf be a slightly better API than
> > passing pointer to a pointer?
>
> I'm not sure it would be simpler to use, since we need to be able to
> indicate -ENOMEM which would presumably become NULL, so the user would have
> to store the existing sheaf pointer and not just blindly do "sheaf =
> refill(sheaf)".

Ack.

> Or the semantics would have to be that in case of failure
> the existing sheaf is returned and caller is left with nothing. Liam, what
> do you think?

That sounds confusing. Compared to that alternative, I would prefer
keeping it the way it is now.

>
> >> +{
> >> +       struct slab_sheaf *sheaf;
> >> +
> >> +       /*
> >> +        * TODO: do we want to support *sheaf == NULL to be equivalent of
> >> +        * kmem_cache_prefill_sheaf() ?
> >> +        */
> >> +       if (!sheafp || !(*sheafp))
> >> +               return -EINVAL;
> >> +
> >> +       sheaf = *sheafp;
> >> +       if (sheaf->size >= size)
> >> +               return 0;
> >> +
> >> +       if (likely(sheaf->capacity >= size)) {
> >> +               if (likely(sheaf->capacity == s->sheaf_capacity))
> >> +                       return refill_sheaf(s, sheaf, gfp);
> >> +
> >> +               if (!__kmem_cache_alloc_bulk(s, gfp, sheaf->capacity - sheaf->size,
> >> +                                            &sheaf->objects[sheaf->size])) {
> >> +                       return -ENOMEM;
> >> +               }
> >> +               sheaf->size = sheaf->capacity;
> >> +
> >> +               return 0;
> >> +       }
> >> +
> >> +       /*
> >> +        * We had a regular sized sheaf and need an oversize one, or we had an
> >> +        * oversize one already but need a larger one now.
> >> +        * This should be a very rare path so let's not complicate it.
> >> +        */
> >> +       sheaf = kmem_cache_prefill_sheaf(s, gfp, size);
> >> +       if (!sheaf)
> >> +               return -ENOMEM;
> >> +
> >> +       kmem_cache_return_sheaf(s, gfp, *sheafp);
> >> +       *sheafp = sheaf;
> >> +       return 0;
> >> +}
> >> +
> >> +/*
> >> + * Allocate from a sheaf obtained by kmem_cache_prefill_sheaf()
> >> + *
> >> + * Guaranteed not to fail as many allocations as was the requested size.
> >> + * After the sheaf is emptied, it fails - no fallback to the slab cache itself.
> >> + *
> >> + * The gfp parameter is meant only to specify __GFP_ZERO or __GFP_ACCOUNT
> >> + * memcg charging is forced over limit if necessary, to avoid failure.
> >> + */
> >> +void *
> >> +kmem_cache_alloc_from_sheaf_noprof(struct kmem_cache *s, gfp_t gfp,
> >> +                                  struct slab_sheaf *sheaf)
> >> +{
> >> +       void *ret = NULL;
> >> +       bool init;
> >> +
> >> +       if (sheaf->size == 0)
> >> +               goto out;
> >> +
> >> +       ret = sheaf->objects[--sheaf->size];
> >> +
> >> +       init = slab_want_init_on_alloc(gfp, s);
> >> +
> >> +       /* add __GFP_NOFAIL to force successful memcg charging */
> >> +       slab_post_alloc_hook(s, NULL, gfp | __GFP_NOFAIL, 1, &ret, init, s->object_size);
> >> +out:
> >> +       trace_kmem_cache_alloc(_RET_IP_, ret, s, gfp, NUMA_NO_NODE);
> >> +
> >> +       return ret;
> >> +}
> >> +
> >> +unsigned int kmem_cache_sheaf_size(struct slab_sheaf *sheaf)
> >> +{
> >> +       return sheaf->size;
> >> +}
> >>  /*
> >>   * To avoid unnecessary overhead, we pass through large allocation requests
> >>   * directly to the page allocator. We use __GFP_COMP, because we will need to
> >>
> >> --
> >> 2.48.1
> >>
>


  reply	other threads:[~2025-04-23 17:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-17 14:33 [PATCH RFC v3 0/8] SLUB percpu sheaves Vlastimil Babka
2025-03-17 14:33 ` [PATCH RFC v3 1/8] locking/local_lock: Introduce localtry_lock_t Vlastimil Babka
2025-03-17 14:33 ` [PATCH RFC v3 2/8] slab: add opt-in caching layer of percpu sheaves Vlastimil Babka
2025-04-03  8:31   ` Harry Yoo
2025-04-03 14:11     ` Vlastimil Babka
2025-04-10 19:51   ` Suren Baghdasaryan
2025-04-22 15:02     ` Vlastimil Babka
2025-03-17 14:33 ` [PATCH RFC v3 3/8] slab: add sheaf support for batching kfree_rcu() operations Vlastimil Babka
2025-04-09  1:50   ` Harry Yoo
2025-04-09 15:09     ` Vlastimil Babka
2025-04-10 20:24   ` Suren Baghdasaryan
2025-04-22 15:18     ` Vlastimil Babka
2025-03-17 14:33 ` [PATCH RFC v3 4/8] slab: sheaf prefilling for guaranteed allocations Vlastimil Babka
2025-04-10 20:47   ` Suren Baghdasaryan
2025-04-23 13:06     ` Vlastimil Babka
2025-04-23 17:13       ` Suren Baghdasaryan [this message]
2025-03-17 14:33 ` [PATCH RFC v3 5/8] slab: determine barn status racily outside of lock Vlastimil Babka
2025-03-17 14:33 ` [PATCH RFC v3 6/8] tools: Add testing support for changes to rcu and slab for sheaves Vlastimil Babka
2025-03-17 14:33 ` [PATCH RFC v3 7/8] tools: Add sheafs support to testing infrastructure Vlastimil Babka
2025-03-17 14:33 ` [PATCH RFC v3 8/8] maple_tree: use percpu sheaves for maple_node_cache Vlastimil Babka

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=CAJuCfpHV7kewvi9kghPAE_JGCBchDDWxe0_LP8_2QkpQePWyDw@mail.gmail.com \
    --to=surenb@google.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=cl@linux.com \
    --cc=harry.yoo@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=maple-tree@lists.infradead.org \
    --cc=rcu@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=urezki@gmail.com \
    --cc=vbabka@suse.cz \
    /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