linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Drokin <green@linuxhacker.ru>
To: Dave Chinner <david@fromorbit.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>,
	cluster-devel@redhat.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH] gfs2: use __vmalloc GFP_NOFS for fs-related allocations.
Date: Wed, 4 Feb 2015 02:13:29 -0500	[thread overview]
Message-ID: <BD2045CE-45AD-4D79-8C8D-C854D112DCC5@linuxhacker.ru> (raw)
In-Reply-To: <20150203223350.GP6282@dastard>

Hello!

On Feb 3, 2015, at 5:33 PM, Dave Chinner wrote:
>> I also wonder if vmalloc is still very slow? That was the case some
>> time ago when I noticed a problem in directory access times in gfs2,
>> which made us change to use kmalloc with a vmalloc fallback in the
>> first place,
> Another of the "myths" about vmalloc. The speed and scalability of
> vmap/vmalloc is a long solved problem - Nick Piggin fixed the worst
> of those problems 5-6 years ago - see the rewrite from 2008 that
> started with commit db64fe0 ("mm: rewrite vmap layer")....

This actually might be less true than one would hope. At least somewhat
recent studies by LLNL (https://jira.hpdd.intel.com/browse/LU-4008)
show that there's huge contention on vmlist_lock, so if you have vmalloc
intense workloads, you get penalized heavily. Granted, this is rhel6 kernel,
but that is still (albeit heavily modified) 2.6.32, which was released at
the end of 2009, way after 2008.
I see that vmlist_lock is gone now, but e.g. vmap_area_lock that is heavily
used is still in place.

So of course with that in place there's every incentive to not use vmalloc
if at all possible. But if used, one would still hopes it would be at least
safe to do even if somewhat slow.

Bye,
    Oleg

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2015-02-04  7:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1422849594-15677-1-git-send-email-green@linuxhacker.ru>
     [not found] ` <20150202053708.GG4251@dastard>
2015-02-02  6:57   ` Oleg Drokin
2015-02-02  8:11     ` Dave Chinner
2015-02-02 10:30       ` Steven Whitehouse
2015-02-03 22:33         ` Dave Chinner
2015-02-04  7:13           ` Oleg Drokin [this message]
2015-02-04  9:49             ` Steven Whitehouse
2015-02-05 20:11               ` Dave Chinner
2015-02-05 11:45             ` Dave Chinner

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=BD2045CE-45AD-4D79-8C8D-C854D112DCC5@linuxhacker.ru \
    --to=green@linuxhacker.ru \
    --cc=cluster-devel@redhat.com \
    --cc=david@fromorbit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=swhiteho@redhat.com \
    /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