All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: linux-ext4@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	"Theodore Ts'o" <tytso@mit.edu>, Jan kara <jack@suse.cz>
Subject: ext4 extent status tree LRU locking
Date: Tue, 11 Jun 2013 16:22:16 -0700	[thread overview]
Message-ID: <51B7B128.60909@intel.com> (raw)

I've got a test case which I intended to use to stress the VM a bit.  It
fills memory up with page cache a couple of times.  It essentially runs
30 or so cp's in parallel.

98% of my CPU is system time, and 96% of _that_ is being spent on the
spinlock in ext4_es_lru_add().  I think the LRU list head and its lock
end up being *REALLY* hot cachelines and are *the* bottleneck on this
test.  Note that this is _before_ we go in to reclaim and actually start
calling in to the shrinker.  There is zero memory pressure in this test.

I'm not sure the benefits of having a proper in-order LRU during reclaim
outweigh such a drastic downside for the common case.

Any thoughts?

             reply	other threads:[~2013-06-11 23:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-11 23:22 Dave Hansen [this message]
2013-06-12  7:17 ` ext4 extent status tree LRU locking Zheng Liu
2013-06-12 15:09   ` Dave Hansen
2013-06-12 16:03     ` Zheng Liu
2013-06-12 17:52       ` Dave Hansen
2013-06-12 20:48     ` Theodore Ts'o
2013-06-13 13:27       ` Zheng Liu
2013-06-13 13:35         ` Theodore Ts'o
2013-06-14  3:27           ` Zheng Liu
2013-06-14 14:09 ` Zheng Liu
2013-06-14 14:02   ` Theodore Ts'o
2013-06-14 17:00     ` Zheng Liu
2013-06-14 18:00       ` Theodore Ts'o
2013-06-17 10:10         ` Zheng Liu
2013-06-17 21:12           ` Dave Hansen
2013-06-18  2:25             ` Zheng Liu
2013-06-18  2:51               ` Theodore Ts'o
2013-06-18  3:49                 ` Zheng Liu
2013-06-18  2:47           ` Theodore Ts'o
2013-06-14 15:57   ` Dave Hansen
2013-06-14 17:11     ` Zheng Liu
2013-06-14 16:55       ` Dave Hansen

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=51B7B128.60909@intel.com \
    --to=dave.hansen@intel.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.