[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200702171417.28376.kernel@kolivas.org>
Date: Sat, 17 Feb 2007 14:17:28 +1100
From: Con Kolivas <kernel@...ivas.org>
To: "michael chang" <thenewme91@...il.com>
Cc: "ck mailing list" <ck@....kolivas.org>,
"linux kernel mailing list" <linux-kernel@...r.kernel.org>
Subject: Re: [ck] Re: 2.6.20-ck1
On Saturday 17 February 2007 13:15, michael chang wrote:
> On 2/16/07, Con Kolivas <kernel@...ivas.org> wrote:
> > I'm thru with bashing my head against the wall.
>
> I do hope this post isn't in any way redundant, but from what I can
> see, this has never been suggested... (someone please do enlighten me
> if I'm wrong.)
>
> Has anyone tried booting a kernel with the various patches in question
> with a mem=###M boot flag (maybe mem=96M or some other "insanely low
> number" ?) to make the kernel think it has less memory than is
> physically available (and then compare to vanilla with the same
> flags)? It might more clearly demonstrate the effects of Con's patches
> when the kernel thinks (or knows) it has relatively little memory
> (since many critics, from what I can tell, have quite a bit of memory
> on their systems for their workloads).
>
> Just my two cents.
Oh that's not a bad idea of course. I've been testing it like that for ages,
and there are many -ck users who have testified to swap prefetch helping in
low memory situations for real as well. Now how do you turn those testimonies
into convincing arguments? Maintainers are far too busy off testing code for
16+ cpus, petabytes of disk storage and so on to try it for themselves. Plus
they worry incessantly that my patches may harm those precious machines'
performance...
--
-ck
-
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