lkml.org 
[lkml]   [2004]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 2.6.5-rc1-mm2 and direct_read_under and wb
Daniel McNeil <daniel@osdl.org> wrote:
>
> The test has been running over 5 hours now without seeing uninitialized
> data. I'll let it run overnight, but it looks like the small
> __block_write_full_page patch fixes the problem.

OK, thanks. It does cause gargantuan amounts of CPU consumption as
expected. The below version fixes that up. I'm not 100% happy with it,
but it seems OK on the profiles.


diff -puN fs/buffer.c~block_write_full_page-redirty fs/buffer.c
--- 25/fs/buffer.c~block_write_full_page-redirty 2004-03-23 01:06:59.281253176 -0800
+++ 25-akpm/fs/buffer.c 2004-03-23 01:09:11.313181272 -0800
@@ -1810,14 +1810,18 @@ static int __block_write_full_page(struc
get_bh(bh);
if (!buffer_mapped(bh))
continue;
- if (wbc->sync_mode != WB_SYNC_NONE) {
+ /*
+ * If it's a fully non-blocking write attempt and we cannot
+ * lock the buffer then redirty the page. Note that this can
+ * potentially cause a busy-wait loop from pdflush and kswapd
+ * activity, but those code paths have their own higher-level
+ * throttling.
+ */
+ if (wbc->sync_mode != WB_SYNC_NONE || !wbc->nonblocking) {
lock_buffer(bh);
- } else {
- if (test_set_buffer_locked(bh)) {
- if (buffer_dirty(bh))
- __set_page_dirty_nobuffers(page);
- continue;
- }
+ } else if (test_set_buffer_locked(bh)) {
+ __set_page_dirty_nobuffers(page);
+ continue;
}
if (test_clear_buffer_dirty(bh)) {
if (!buffer_uptodate(bh))
_

-
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:01    [from the cache]
©2003-2011 Jasper Spaans