[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120413182227.GY17822@one.firstfloor.org>
Date: Fri, 13 Apr 2012 20:22:27 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Ted Ts'o <tytso@....edu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>,
Vivek Haldar <haldar@...gle.com>,
Andreas Dilger <adilger@...ger.ca>, linux-ext4@...r.kernel.org,
tim.c.chen@...ux.intel.com
Subject: Re: [RFC, PATCH] Avoid hot statistics cache line in ext4 extent cache
> I think Andi cited the wrong commit. The commit in question is
> 77f4135f2a219a2127be6cc1208c42e6175b11dd, which first showed up in
> 2.6.39. If you have a very fast (PCIe-attached would be required I
I don't think it was a highend IO device.
This already hits for buffered IO I think.
> I'm willing to push commit to you to remove the counters for now, and
> we'll probably add it back later using percpu counters if you think
> it's worth making a change at this time --- or if Andi can explain why
> he's treating this with a high degree of urgency. Is there some
> common use case that I'm missing which is being very badly impacted
> with this cache-line thrashing?
Well IO writes is a pretty common use case. On a smaller
system it's likely not ~30%, but likely a drag too. And we normally
try to fix scalability regressions each release. Otherwise things
will just get worse and worse over time.
Scalability is unfortunately quite fragile and needs constant
attention. Every bad hot cache line can break it.
So yes I would like this to be reverted for the release.
-Andi
--
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists