Stephen, are we really sure we still need kpiod? Isn't GFP_IO meant to be
clear if anybody is helding any filesystem lock (like superblock lock)?
The fact is that we don't do any write-throttling in swap_out due kpiod
async nature. If we would do_write_page then we would do the write
throttling in the balance_dirty code while generating the dirty buffers in
write(2) and things would be probably go much better with respect of
memory allocations. While now swap_out returns succes in a hurry without
doing any progress. This is of course ok for the places that can't swapout
at all but when we have GFP_IO set we should be able to write to the fs
(otherwise what is GFP_IO meant for? if writing to the fs isn't safe when
we have GFP_IO set then swapfile (as opposed to swap device) wouldn't be
safe either). So it looks like to me I can drop kpiod but please tell me
if I'm missing something.
I see only one place that is using GFP_IO even while it grabs the
superblock lock and that looks a bug in 2.2.17pre9:
--- 2.2.17pre9/fs/ext2/super.c Mon Jan 17 16:44:42 2000
+++ /tmp/p Mon Jul 3 13:20:12 2000
@@ -589,7 +589,7 @@
EXT2_BLOCKS_PER_GROUP(sb);
db_count = (sb->u.ext2_sb.s_groups_count + EXT2_DESC_PER_BLOCK(sb) - 1) /
EXT2_DESC_PER_BLOCK(sb);
- sb->u.ext2_sb.s_group_desc = kmalloc (db_count * sizeof (struct buffer_head *), GFP_KERNEL);
+ sb->u.ext2_sb.s_group_desc = kmalloc (db_count * sizeof (struct buffer_head *), GFP_BUFFER);
if (sb->u.ext2_sb.s_group_desc == NULL) {
printk ("EXT2-fs: not enough memory\n");
goto failed_mount;
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:12 EST