Re: extent-patch and overview of what is supposed to follow

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Lars Heidieker <lars%heidieker.de@localhost> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/02/11 02:31, Mindaugas Rasiukevicius wrote:
> >
> > I think it would be better to convert malloc(9) to kmem(9) where
> > possible before the merger. So we could better see what is left
> > i.e. what memory allocations are performed from interrupt context.
> >
> > There is one strong concern. Merging means converting kmem(9) to
> > use interrupt-safe map, therefore raised IPL and more blocking of
> > interrupts. That is not desirable, as interrupt handlers should
> > generally avoid memory allocation - it seems we all agree that
> > variable-sized allocations there indicate a flaw, and for
> > constant-sized allocations pool_cache(9) or some pre-allocation
> > mechanisms should be used.
> >
> > Hence, as we try to do less work in the interrupt handlers, change
> > to main memory allocator, resulting in higher "SPL-ing", seems
> > counter-productive.
> >
> > I would like to see more thoughts from more engineers, particularly
> > yamt@.
> >
> 
> I've spend some time thinking about this and think you are right, this
> is got possibility to identify those in-interrupt context allocations
> and convert them to either use dedicated interrupt safe pools are move
> the allocation out of the interrupt context.
> Allocating from a general memory allocator interrupt safe isn't a nice
> design in my eyes too.
> In the end only some allocations should be left, those that require a
> malloc / free like interface but those should not require interrupt
> safety and then they can be replaced by small wrapper around kmem.

OK. :)

> Am working on changing the patch and removing the necessity of the
> pool_allocator to use malloc for it's log structures (done but untested)

Do you mean POOL_DIAGNOSTIC?  Some time ago, I have seen a bug indicating
that facility was not really used for years (unless my memory is confused).
I doubt it is that useful these days, so my suggestion would rather be to
remove it (and keep interface clean, without macros).  Instead, we should
have a general purpose UVMHIST-like logging facility.

-- 
Mindaugas