[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070512011454.50ba68a5.pj@sgi.com>
Date: Sat, 12 May 2007 01:14:54 -0700
From: Paul Jackson <pj@....com>
To: Con Kolivas <kernel@...ivas.org>
Cc: nickpiggin@...oo.com.au, ray-lk@...rabbit.org, mingo@...e.hu,
ck@....kolivas.org, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm: swap prefetch improvements
> Ummm this is what I've been saying for over a year now but noone has been
> listening.
Well ... if there is a problem using prefetch and cpusets together,
it doesn't look like the two of us are going to find it.
I should probably look at your patch to answer this next question,
but being a lazy retard, I'll just ask. Is there a way, on a running
system that has your prefetch patch configured in, to disable prefetch
-- perhaps writing to some magic /proc file or something?
If so, then how about you just remove the lines in the patch that
disable prefetch on kernels configured with CPUSETS, and we charge
ahead allowing both at the same time?
If some day in the future I find something about prefetch that harms
the HPC NUMA loads I care about, then I can just dynamically disable
prefetch.
If someone ever uncovers a real problem with prefetch and cpusets,
then we will deal with it then.
As to whether your patch is otherwise (other than cpusets) worthy
of further acceptance, that I will have to leave up to those who are
competent to make such judgements.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@....com> 1.925.600.0401
-
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