Lars Heidieker <[email protected]> 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
