On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote: > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote: > > > > It must be > > possible to process more than 2 mappings in softirq context. > > Adding a few more fixmap slots wouldn't hurt anyone. But if you want an > arbitrarily large number of them then no, we cannot do that.
What magnitude is "few more"? 2, 10, 100? > Taking more than one sleeping kmap at a time within the same process is > deadlocky, btw. You can end up with N such tasks all holding one kmap and > waiting for someone else to release one. > > Possibly one could arrange for the pages to not be in highmem at all. Is there an easy way to bring pages to lowmem? The cryptoapi is called from the backlog of the networking stack, which is assigned in irq context first and processed softirq context. There is little opportunity to bringt stuff to low mem. And we can't bringt stuff to lowmem on our own as well, because (as I guess) this involves a page allocation, which would have to be GFP_ATOMIC, which can fail. So we would need fallback for the fallback mechanism, and that's still the tiny set of scratch buffers.. hairy business.. Ok, what about the following plan: If context == softirq, use kmap_atomic until they all used, fall-back to scratch buffers, and printk in some DEBUG mode:"Warning slow, redesign your client or raise the number of fixmaps". If context == user, use kmap_atomic until they all used, and fall-back to kmap. -- Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
