[<prev] [next>] [day] [month] [year] [list]
Message-Id: <1236238649.5330.10132.camel@laptop>
Date: Thu, 05 Mar 2009 08:37:29 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
Cc: Wu Fengguang <fengguang.wu@...el.com>,
"Lin, Ming M" <ming.m.lin@...el.com>,
Nick Piggin <npiggin@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [Bug #12809] iozone regression with 2.6.29-rc6
(list restored)
On Thu, 2009-03-05 at 10:13 +0800, Zhang, Yanmin wrote:
> My idea:
> 1) When the main thread traps into kernel and find need to write back pages; it just starts
> write back, but it needn't change timestamp (???or something like that) on writeback; and start
> pdflush;
> 2) Later on pdflush could pick up the file to write back for other pages on the same file;
> 3) The target is to let pdflush to writeback pages and main testing thread continues on its own
> work, so we can benefit from SMP.
No!
This is not about parallelism, this is about making sure there is a
limited number of dirty pages, that means the tasks generating dirty
pages will _have_ to wait. You simply cannot delegate that.
Furthermore, the task throttling explicitly wants to throttle the task
that generates all those dirty pages more than other tasks. So pushing
the throttle out to pdflush will destroy the whole scheme.
The reason we want to make the heavy dirtier throttle sooner is that
other tasks, who only occasionally dirty a page, don't get caught in the
massive throttle latency.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists