[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130926003315.2e81bc84.akpm@linux-foundation.org>
Date: Thu, 26 Sep 2013 00:33:15 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Peter Hurley <peter@...leysoftware.com>
Cc: Fengguang Wu <fengguang.wu@...el.com>,
Greg KH <gregkh@...uxfoundation.org>,
LKML <linux-kernel@...r.kernel.org>, lkp@...org,
Tejun Heo <tj@...nel.org>
Subject: Re: increased vmap_area_lock contentions on
"n_tty: Move buffers into n_tty_data"
On Tue, 17 Sep 2013 20:22:42 -0400 Peter Hurley <peter@...leysoftware.com> wrote:
> Looking over vmalloc.c, the critical section footprint of the vmap_area_lock
> could definitely be reduced (even nearly eliminated), but that's a project for
> another day :)
20bafb3d23d10 ("n_tty: Move buffers into n_tty_data") switched a
kmalloc (which is very fast) to a vmalloc (which is very slow) without
so much as mentioning it in the changelog. This should have been
picked up at review, btw.
Revert that part of the patch and the problem will be solved.
If we are really really worried that a ~9k kmalloc might fail or will
be slow, then implement a fallback to vmalloc() if kmalloc(GFP_NOWARN)
failed. This kinda sucks, but is practical, but really should only be
done if necessary - ie, if problems with using plain old kmalloc are
demonstrable.
Or just revert all of 20bafb3d23d10 - it was supposed to be a small
performance improvement but turned out to be a significant performance
loss. Therefore zap.
--
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