Re: [PATCH 1/2] mm: slub: allocate slab object extensions non-contiguously

[Kent Overstreet <kent.overstreet@linux.dev>]

On Tue, May 20, 2025 at 10:20:23AM -0700, Suren Baghdasaryan wrote:
> On Tue, May 20, 2025 at 9:41 AM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
> I see your point. One case we would want to use vmalloc is if the
> allocation is sizable (multiple pages), so failing it does not mean
> critical memory pressure level yet. I don't think today's extension
> vectors would be large enough to span multiple pages. That would
> require a rather large obj_per_slab and in most cases I think this
> change would not affect current behavior, the allocations will be
> smaller than PAGE_SIZE and kvmalloc will fail anyway.
> I guess the question is whether we want to fail if allocation size is
> higher than PAGE_SIZE but less than PAGE_ALLOC_COSTLY_ORDER. Failing
> that I think is reasonable and I don't think any extension vector will
> be large enough to reach PAGE_ALLOC_COSTLY_ORDER. So, I'm ok with
> dropping this part of the patchset.

Johannes raisess more pertinent points, so I think vmalloc allocation is
out.

If it turns out that extension vector allocation failures do cause real
problems (not for memory allocation profiling, but maybe someone is
depending on memcg being precise), I think it would acceptable to dip
into reserves for them, since they're a small fraction of the slabs
themselves.

With the caveat that we'd need to look at how the reserves are sized, to
make sure we're not running them empty and causing new problems
elsewhere.

But just failing the allocation should probably be the default approach
here.