From: Peter Hurley <peter@hurleysoftware.com>
To: lkp@lists.01.org
Subject: Re: increased vmap_area_lock contentions on "n_tty: Move buffers into n_tty_data"
Date: Thu, 26 Sep 2013 17:42:52 -0400 [thread overview]
Message-ID: <5244AA5C.8060100@hurleysoftware.com> (raw)
In-Reply-To: <20130926110551.52ad8156.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On 09/26/2013 02:05 PM, Andrew Morton wrote:
> On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley <peter@hurleysoftware.com> wrote:
>
>> The issue with a single large kmalloc is that it may fail where
>> 3 separate, page-or-less kmallocs would not have.
>
> Or vmalloc fails first, because of internal fragmentation of the vmap
> arena. This problem plus vmalloc's slowness are the reasons why
> vmalloc should be avoided.
Ok, no vmalloc.
> A tremendous number of places in the kernel perform higher-order
> allocations nowadays. The page allocator works damn hard to service
> them and I expect that switching to kmalloc here will be OK.
I've had order-4 allocation failures before on 10Gb. In fact, the
nouveau driver switched to vmalloc for that very reason (commit
d005f51eb93d71cd40ebd11dd377453fa8c8a42a, drm/nouveau: use vmalloc
for pgt allocation).
Regards,
Peter Hurley
WARNING: multiple messages have this Message-ID (diff)
From: Peter Hurley <peter@hurleysoftware.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Fengguang Wu <fengguang.wu@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
lkp@01.org, Tejun Heo <tj@kernel.org>
Subject: Re: increased vmap_area_lock contentions on "n_tty: Move buffers into n_tty_data"
Date: Thu, 26 Sep 2013 17:42:52 -0400 [thread overview]
Message-ID: <5244AA5C.8060100@hurleysoftware.com> (raw)
In-Reply-To: <20130926110551.52ad8156.akpm@linux-foundation.org>
On 09/26/2013 02:05 PM, Andrew Morton wrote:
> On Thu, 26 Sep 2013 13:35:32 -0400 Peter Hurley <peter@hurleysoftware.com> wrote:
>
>> The issue with a single large kmalloc is that it may fail where
>> 3 separate, page-or-less kmallocs would not have.
>
> Or vmalloc fails first, because of internal fragmentation of the vmap
> arena. This problem plus vmalloc's slowness are the reasons why
> vmalloc should be avoided.
Ok, no vmalloc.
> A tremendous number of places in the kernel perform higher-order
> allocations nowadays. The page allocator works damn hard to service
> them and I expect that switching to kmalloc here will be OK.
I've had order-4 allocation failures before on 10Gb. In fact, the
nouveau driver switched to vmalloc for that very reason (commit
d005f51eb93d71cd40ebd11dd377453fa8c8a42a, drm/nouveau: use vmalloc
for pgt allocation).
Regards,
Peter Hurley
next prev parent reply other threads:[~2013-09-26 21:42 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 0:51 increased vmap_area_lock contentions on "n_tty: Move buffers into n_tty_data" Fengguang Wu
2013-09-13 0:51 ` Fengguang Wu
2013-09-13 1:09 ` Fengguang Wu
2013-09-13 1:09 ` Fengguang Wu
2013-09-17 15:34 ` Peter Hurley
2013-09-17 15:34 ` Peter Hurley
2013-09-17 23:22 ` Fengguang Wu
2013-09-17 23:22 ` Fengguang Wu
2013-09-18 0:22 ` Peter Hurley
2013-09-18 0:22 ` Peter Hurley
2013-09-25 9:04 ` Lin Ming
2013-09-25 9:04 ` Lin Ming
2013-09-25 11:30 ` Peter Hurley
2013-09-25 11:30 ` Peter Hurley
2013-09-25 14:53 ` Lin Ming
2013-09-25 14:53 ` Lin Ming
2013-09-25 16:02 ` Lin Ming
2013-09-25 16:02 ` Lin Ming
2013-09-26 3:20 ` Andi Kleen
2013-09-26 3:20 ` Andi Kleen
2013-09-26 11:52 ` Peter Hurley
2013-09-26 11:52 ` Peter Hurley
2013-09-26 15:32 ` Andi Kleen
2013-09-26 15:32 ` Andi Kleen
2013-09-26 17:22 ` Peter Hurley
2013-09-26 17:22 ` Peter Hurley
2013-09-26 7:33 ` Andrew Morton
2013-09-26 7:33 ` Andrew Morton
2013-09-26 11:31 ` Peter Hurley
2013-09-26 11:31 ` Peter Hurley
2013-09-26 15:04 ` Greg KH
2013-09-26 15:04 ` Greg KH
2013-09-26 17:35 ` Peter Hurley
2013-09-26 17:35 ` Peter Hurley
2013-09-26 18:05 ` Andrew Morton
2013-09-26 18:05 ` Andrew Morton
2013-09-26 21:42 ` Peter Hurley [this message]
2013-09-26 21:42 ` Peter Hurley
2013-09-26 21:58 ` Andrew Morton
2013-09-26 21:58 ` Andrew Morton
2013-09-26 22:21 ` Peter Hurley
2013-09-26 22:21 ` Peter Hurley
2013-09-18 0:49 ` Peter Hurley
2013-09-18 0:49 ` Peter Hurley
2013-09-13 3:17 ` Greg KH
2013-09-13 3:17 ` Greg KH
2013-09-13 3:38 ` Fengguang Wu
2013-09-13 3:38 ` Fengguang Wu
2013-09-13 3:44 ` Greg KH
2013-09-13 3:44 ` Greg KH
2013-09-13 9:55 ` Peter Hurley
2013-09-13 9:55 ` Peter Hurley
2013-09-13 12:34 ` Greg KH
2013-09-13 12:34 ` Greg KH
2013-09-17 2:42 ` Peter Hurley
2013-09-17 2:42 ` Peter Hurley
2013-09-17 2:56 ` Fengguang Wu
2013-09-17 2:56 ` Fengguang Wu
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=5244AA5C.8060100@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=lkp@lists.01.org \
/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.