Fruhwirth Clemens <[EMAIL PROTECTED]> wrote: > > 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?
Not 100. 10 would seem excessive. > > 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. Are networking frames ever allocated from highmem? Don't think so. > 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.. yup. > 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". Sounds painful. > If context == user, use kmap_atomic until they all used, and fall-back > to kmap. Taking multiple kmaps can deadlock due to kmap exhaustion though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
