That leads to block_flushpage() being called under spinlock against a
page which has locked buffers, so it schedules on the buffer lock and
the box deadlocks.
So... can do, but I'll have to sort out the block_flushpage-under-spinlock
problem in the process.
But I recall you saying that there was advantage in keeping swapout pages
locked so that aggressive memory users would throttle against their
own swapout. What's the story there?
Generally, there are a number of irritating swap special-cases popping up
and yes, it would be nice to give swap a proper inode, superblock (maybe)
and a get_block so it can become more regular. One obstacle there is
the PAGE_SIZE versus PAGE_CACHE_SIZE thing. Would have to add a new
address_space.page_size for that, which would penalise other address_spaces
slightly (in terms of memory usage and code size).
I've been trying to not look at the swap code ;) But there will be some
benefit it teaching swap to go direct to BIO to avoid the extra buffer
allocations when things are squeezy. So I do need to stick my nose in
there.
-
-
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/