Re: [bug report] scsi: sd_zbc: emulate ZONE_APPEND commands

[Michal Hocko <mhocko@suse.com>]

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