Messages in this thread Patch in this message | | | Date | Mon, 3 Jul 2000 13:28:48 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: More 2.2.17pre9 VM issues |
| |
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/
| |