linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Ted Ts'o <tytso@mit.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andi Kleen <andi@firstfloor.org>,
	Vivek Haldar <haldar@google.com>,
	Andreas Dilger <adilger@dilger.ca>,
	linux-ext4@vger.kernel.org, tim.c.chen@linux.intel.com
Subject: Re: [RFC, PATCH] Avoid hot statistics cache line in ext4 extent cache
Date: Fri, 13 Apr 2012 20:22:27 +0200	[thread overview]
Message-ID: <20120413182227.GY17822@one.firstfloor.org> (raw)
In-Reply-To: <20120413180603.GF26332@thunk.org>

> 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@linux.intel.com -- Speaking for myself only.

      reply	other threads:[~2012-04-13 18:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-23 22:17 [RFC, PATCH] Avoid hot statistics cache line in ext4 extent cache Andi Kleen
2012-03-24  1:10 ` Andreas Dilger
2012-03-24  3:13   ` Andi Kleen
2012-03-26 22:26     ` Vivek Haldar
2012-03-26 23:00       ` Andi Kleen
2012-03-26 23:57         ` Ted Ts'o
2012-04-11 16:59           ` Andi Kleen
2012-04-13 17:42             ` Linus Torvalds
2012-04-13 17:53               ` Tim Chen
2012-04-13 18:08                 ` Linus Torvalds
2012-04-13 18:31                   ` Tim Chen
2012-04-13 18:33                     ` Linus Torvalds
2012-04-13 18:37                     ` Ted Ts'o
2012-04-13 18:41                       ` Andi Kleen
2012-04-13 18:48                         ` Ted Ts'o
2012-04-13 19:01                           ` Eric Whitney
2012-04-13 19:26                       ` Tim Chen
2012-04-13 19:33                         ` Ted Ts'o
2012-04-13 17:57               ` Andi Kleen
2012-04-13 18:06               ` Ted Ts'o
2012-04-13 18:22                 ` Andi Kleen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120413182227.GY17822@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=adilger@dilger.ca \
    --cc=haldar@google.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).