On Wed 17-02-21 09:08:07, Johannes Thumshirn wrote:
> On 17/02/2021 09:03, Michal Hocko wrote:
> >> No I don't think so. A mutex isn't a spinlock so we can sleep on the allocation.
> >> We can't use GFP_KERNEL as we're about to do I/O. blk_revalidate_disk_zones() called
> >> a few line below also does the memalloc_noio_{save,restore}() dance.
> >
> > You should be extending noio scope then if this allocation falls into
> > the same category. Ideally the scope should start at the recursion place
> > and end where the scope really ened.
>
> That means all callers of blk_revalidate_disk_zones() should do
> memalloc_noio_{save,restore}?
I am not really familiar with the IO area to answer this. The base idea
is to start the NOIO scope at the boundary which defines "unsafe to
re-enter or cannot deal with a new IO" from the reclaim path.
> If yes, can we somehow runtime assert that this is done, so we don't
> end up with bad surprises?
Could you elaborate?
> >> Would a kmem_cache for these revalidations help us in any way?
> >
> > I am not sure what you mean here.
> >
>
> Using a kmem_cache for the allocations passed into blk_revalidate_disk_zones().
> I've looked into kmem_cache_alloc() and I couldn't find anything that speaks
> against it, but I'm not too familiar with the code.
kmem_cache_alloc is only an extension to allow to allocate from a
specific cache. I do not really see how it is going to help with larger
allocation and my current understanding is that kvmalloc is used because
the requested allocation size can be large.
--
Michal Hocko
SUSE Labs
