[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090525114135.GD29447@sgi.com>
Date: Mon, 25 May 2009 06:41:35 -0500
From: Robin Holt <holt@....com>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc: Robin Holt <holt@....com>, LKML <linux-kernel@...r.kernel.org>,
linux-mm <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
Christoph Lameter <cl@...ux-foundation.org>,
"Zhang, Yanmin" <yanmin.zhang@...el.com>,
Wu Fengguang <fengguang.wu@...el.com>
Subject: Re: [PATCH v3] zone_reclaim is always 0 by default
On Sun, May 24, 2009 at 10:44:29PM +0900, KOSAKI Motohiro wrote:
...
> > Your root cause analysis is suspect. You found a knob to turn which
> > suddenly improved performance for one specific un-tuned server workload.
...
> The fact is, workload dependency charactetistics of zone reclaim is
> widely known from very ago.
> Even Documentaion/sysctl/vm.txt said,
>
> > It may be beneficial to switch off zone reclaim if the system is
> > used for a file server and all of memory should be used for caching files
> > from disk. In that case the caching effect is more important than
> > data locality.
>
> Nobody except you oppose this.
I don't disagree with that statement. I agree this is a workload specific
tuneable that for the case where you want to use the system for nothing
other than file serving, you need to turn it off. It has been this way
for ages. I am saying let's not change that default behavior.
> > How did you determine better by default? I think we already established
> > that apache is a server workload and not a desktop workload. Earlier
> > you were arguing that we need this turned off to improve the desktop
> > environment. You have not established this improves desktop performance.
> > Actually, you have not established it improves apache performance or
> > server performance. You have documented it improves memory utilization,
> > but that is not always the same as faster.
>
> The fact is, low-end machine performace depend on cache hitting ratio widely.
> improving memory utilization mean improving cache hitting ratio.
>
> Plus, I already explained about desktop use case. multiple worst case scenario
> can happend on it easily.
>
> if big process consume memory rather than node size, zone-reclaim
> decrease performance largely.
It may improve performance as well. I agree we can come up with
theoretical cases that show both. I am asking for documented cases where
it does. Your original post indicated an apache regression. In that
case apache was being used under server type loads. If you have a machine
with this condition, you should probably be considered the exception.
> zone reclaim decrease page-cache hitting ratio. some desktop don't have
> much memory. cache missies does'nt only increase latency, but also
> increase unnecessary I/O. desktop don't have rich I/O bandwidth rather than
> server or hpc. it makes bad I/O affect.
If low I/O performance should be turning it off, then shouldn't that
case be coded into the default as opposed to changing the default to
match your specific opinion?
> However, your past explanation is really wrong and bogus.
> I wrote
>
> > If this imbalance is an x86_64 only problem, then we could do something
> > simple like the following untested patch. This leaves the default
> > for everyone except x86_64.
>
> and I wrote it isn't true. after that, you haven't provide addisional
> explanation.
I don't recall seeing your response. Sorry, but this has been, and will
remain, low priority for me. If the default gets changed, we will detect
the performance regression very early after we start testing this bad
of a change on a low memory machine and then we will put a tweak into
place at the next distro release to turn this off following boot.
> Nobody ack CODE-ONLY-PATCH. _You_ have to explain _why_ you think
> your approach is better.
Because it doesn't throw out a lot of history based upon your opinion of
one server type test found under lab conditions on a poorly tuned machine.
Robin
--
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