[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxEfKTeGmX57R0s+2MaQwfgqvVnf+M3zkwNk0rN0j7Ksg@mail.gmail.com>
Date: Sat, 2 Mar 2013 11:54:37 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Theodore Ts'o" <tytso@....edu>, Dave Jones <davej@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
"gnehzuil.liu" <gnehzuil.liu@...il.com>,
Zheng Liu <wenqing.lz@...bao.com>,
Borislav Petkov <bp@...en8.de>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL URGENT] ext4 regression fix for 3.9
On Thu, Feb 28, 2013 at 8:00 PM, Theodore Ts'o <tytso@....edu> wrote:
>
> ext4_es_reclaim_extents_count() is getting called out of the slab
> shrinker. It's getting called too often when there is significant
> memory pressure. We can optimize this so we're not calculating it all
> the time.
This needs to be fixed or reverted. I traced back some user
interaction problems to this same issue. It literally gets so bad that
the whole system is choppy, and a profile shows that a lot of time is
being spent in the spin-lock protecting these data structures. Called
from ext4_es_reclaim_extents_count, ext4_es_lru_add and
ext4_es_shrink.
We're talking very user-noticeable pauses, so it's not just the
spinlock, there's some real badness that comes in with it too.
Possibly related to other (sleeping) locks being held while the data
structures are then refilled or something.
Linus
--
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