[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200707270004.46211.dirk@liji-und-dirk.de>
Date: Fri, 27 Jul 2007 00:04:38 +0200
From: Dirk Schoebel <dirk@...i-und-dirk.de>
To: ck@....kolivas.org
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"Michael Chang" <thenewme91@...il.com>,
Nick Piggin <nickpiggin@...oo.com.au>,
Ray Lee <ray-lk@...rabbit.org>,
Eric St-Laurent <ericstl34@...patico.ca>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Paul Jackson <pj@....com>, Jesper Juhl <jesper.juhl@...il.com>,
Rene Herman <rene.herman@...il.com>
Subject: Re: [ck] Re: -mm merge plans for 2.6.23
I don't really understand the reasons for all those discussions.
As long as you have a maintainer, why don't you just put swap prefetch into
the kernel, marked experimental, default deactivated so anyone who just
make[s] oldconfig (or defaultconfig) won't get it. If anyone finds a good
solution for all those cache 'poisoning' problems and problems concerning
swapin on workload changes and such swap prefetch can easily taken out again
and no one has to complain and continuing maintaining it.
Actually the same goes for plugshed (having it might have kept Con as a
valuable developer).
I am actually waiting for more than 2 years that reiser4 will make it into the
kernel (sure, marked experimental or even highly experimental) so the
patch-journey for every new kernel comes to an end. And most things in-kernel
will surely be tested more intense so bugs will come up much faster.
(Constantly running MM kernels is not really an option since many things in
there can't be deactivated if they don't work as expected since lots of
patches also concern 'vital' parts of the kernel.)
...just 2cents from a happy CK user for it made it possible to watch a movie
while compiling the system - which was impossible with mainline kernel, even
on dual core 2.2 GHz AMD64 with 4G RAM !
Dirk.
Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists