![]() | |||||||||||||
Messages in this thread |
On Thu, 2004-02-05 at 16:07, Andrew Morton wrote: > Daniel McNeil <daniel@osdl.org> wrote: > > > > Andrew, > > > > I tested 2.6.2-mm1 on an 8-proc running 6 copies of the read_under > > test and all 6 read_under tests saw uninitialized data in less than 5 > > minutes. :( > > The performance implications of synchronising behind kjournald writes for > normal non-blocking writeback are bad. Can you detail what you now think > is the failure mechanism? > I think the problem is that any block_write_full_page(WB_SYNC_NONE) that hits a page that has a buffer in process of being written will get PageWriteback cleared even though the i/o has not completed. (The buffer will be locked, but buffer_dirty() is cleared, so __block_write_full_page() will SetPageWriteback(); unlock_page(); see no buffer were submitted and call end_page_writeback()) Any subsequent filemap_write_and_wait() or filemap_fdatawrite() / filemap_fdatawait will never wait for that i/o. So this could potentially be a problem for more than just DIO. BTW: 2.4 __block_write_full_page() always did a lock_buffer(), so it waits for i/o in flight. I agree though, it would be best if non-sync __block_write_full_page() would not block on buffers in flight. Somehow we need to move the clearing of PageWriteback() until after the buffer has been written even for the case where ll_rw_block() is called. Thoughts? Daniel - 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/ | ||||||||||||
| Last update: 2005-03-22 14:00 [W:0.159 / U:0.340 seconds] ©2003-2008 Jasper Spaans | |||||||||||||