No particularly good ones, I'm afraid. Options appear to be:
1: Lose data if the pages are swapcache or pagecache.
2: Make mapping->page_lock and mapping->private_lock irq-safe,
and mandate that a_ops->set_page_dirty be callable from
interrupt context.
3: Hang onto the BIOs and find a process somewhere to mark the
pages dirty and then release them after IO has completed.
None of these are particularly palatable. But if this is a
showstopper for async IO against raw devices, and a showstopper
for async IO against O_DIRECT blockdevs and a showstopper for
async IO against O_DIRECT files (is it?) then I guess we clench
the teeth and go for option 2.
Holding onto gazillions of BIOs and punting it all up to keventd
some time in the future would be lame. Making those locks and these
codepaths irq-safe is consistent with the general tougher, tighter
and more async direction in which the 2.5 IO paths are headed, so...
With the radix-tree gang lookup and truncate rework I expect that
the maximum hold time of those locks is miniscule, so interrupt
latency isn't a concern here. (It would be 50 milliseconds or
more at present...)
ho-hum. I'll do the patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/