Date: Wed, 7 Dec 2005 01:46:59 -0800
From: Andrew Morton <akpm@osdl.org>
To: Wu Fengguang <wfg@mail.ustc.edu.cn>
Cc: nikita@clusterfs.com, Linux-Kernel@vger.kernel.org
Subject: Re: [PATCH 01/16] mm: delayed page activation
Message-Id: <20051207014659.512619ea.akpm@osdl.org>
In-Reply-To: <20051207014235.GA5186@mail.ustc.edu.cn>
References: <20051203071444.260068000@localhost.localdomain>
	<20051203071609.755741000@localhost.localdomain>
	<17298.56560.78408.693927@gargle.gargle.HOWL>
	<20051204134818.GA4305@mail.ustc.edu.cn>
	<17299.1331.368159.374754@gargle.gargle.HOWL>
	<20051205014842.GA5103@mail.ustc.edu.cn>
	<17301.53377.614777.913013@gargle.gargle.HOWL>
	<20051207014235.GA5186@mail.ustc.edu.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1572
Lines: 30

Wu Fengguang <wfg@mail.ustc.edu.cn> wrote:
>
> Andrew, and anyone in the lkml, do you feel ok to test it in -mm tree?

Nope, sorry.  I am wildly uninterested in large changes to page reclaim. 
Or to readahead, come to that.

That code has had years of testing, tweaking, tuning and poking.  Large
changes such as these will take as long as a year to get settled into the
same degree of maturity.  Both of these parts of the kernel are similar in
that they are hit with an extraordinarly broad range of usage patterns and
they both implement various predict-the-future heuristics.  They are subtle
and there is a lot of historical knowledge embedded in there.

What I would encourage you to do is to stop developing and testing new
code.  Instead, devote more time to testing, understanding and debugging
the current code.  If you find and fix a problem and can help us gain a
really really really good understanding of the problem and the fix then
great, we can run with that minimal-sized, minimal-impact, well-understood,
well-tested fix.

See where I'm coming from?  Experience teaches us to be super-cautious
here.  In these code areas especially we cannot afford to go making
larger-than-needed changes because those changes will probably break things
in ways which will take a long time to discover, and longer to re-fix.
-
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/