Re: Temporary memory allocation from interrupt context

[Lars Reichardt <lars%paradoxon.info@localhost>]

On Wed, 11 Nov 2020 07:32:56 -0800
Jason Thorpe <thorpej%me.com@localhost> wrote:

> > On Nov 11, 2020, at 5:38 AM, Martin Husemann <martin%duskware.de@localhost>
> > wrote:
> > 
> > Yes, and of course the real code has that (and works). It's just
> > that 
> > - memoryallocators(9) does not cover this case
> > - kmem_intr_alloc(9) is kinda deprecated - quoting the man page:
> > 
> > 	These routines are for the special cases.  Normally,
> > 	pool_cache(9) should be used for memory allocation from
> > interrupt context.
> > 
> >   but how would I use pool_cache(9) here?  
> 
> It's not "deprecated" per se.  Heck, kmem_intr_alloc() was added
> *after* the pool cache API was added :-).  Sounds to me like
> memoryallocators(9) needs to be combed through and updated.
> 
> Anyway, I think what the documentation is trying to convey is that
> "pool_cache is better if you are allocating and freeing fixed size
> objects in a hot code path".  However, you're not allocating
> fixed-size objects, so using pool_cache directly is not appropriate.
> Using kmem_intr_alloc() is preferable to rolling your own logic here,
> and gets you the optimal behavior for this use case.
> 
> -- thorpej
> 

The kmem_intr_alloc is a replacement for the old malloc.

I think dedicated pool_cache is useful if either there is a custom
constructor/destructor or a lot of allocations to save some memory due
to better fitting but that savings have to make up against the
pool_cache structures itself.
That's why we have kmem_intr_alloc a pool_cache just to have a
interrupt safe allocator for a single use case is, simply spoken, just
an enormous overhead.

I was/am under the impression that the longtime goal is to move all
allocations out of interrupt paths and that kmem_intr_alloc is there
only for transition, I have doubts this will happen.
Don't get me wrong moving allocations out of interrupt paths is a good
thing.

Technically kmem_alloc and kmem_intr_alloc are backed by the same pools
so the distinction is only API wise.
(I have a patch using different pool_caches for kmem_alloc and
kmem_intr_alloc it enforces that distinctions and allows some paths in
kmem_allocs pool_caches to skip interrupt disabling... I have no
idea/measured how much of a difference this makes)

Most systems I've looked at just have the equivalent of kmem_intr_alloc.

Having to block on deallocation is even worse but lukily we don't.
If I haven't missed anything technically kmem_intr_free does no
allocations for freeing resources, there is one allocation but if it
fails we skip caching the chunk of memory and return it directly.
(Even that could be tackled by having a bound number of
pool_cache_groups per pool_cache per cpu)
No allocation on the free path is a nice property of vmem.

para

-- 
You will continue to suffer
if you have an emotional reaction to everything that is said to you.
True power is sitting back and observing everything with logic.
If words control you that means everyone else can control you.
Breathe and allow things to pass.

--- Bruce Lee