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

[Lars Heidieker <lars%heidieker.de@localhost>]

-----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.

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)

Lars
 

- -- 
- ------------------------------------

Mystische Erklärungen:
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind.

   -- Friedrich Nietzsche
   [ Die Fröhliche Wissenschaft Buch 3, 126 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Y2BkACgkQcxuYqjT7GRbhZQCgwN4BIYWC5yeOE6VgMvuXdy6q
r9oAnRnN3sFvdEy0M2xn5eS6RVbLShxe
=AZo3
-----END PGP SIGNATURE-----