> On Nov 11, 2020, at 5:38 AM, Martin Husemann <mar...@duskware.de> 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
