From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Date: Thu, 5 Feb 2015 22:45:00 +1100 Subject: [Cluster-devel] [PATCH] gfs2: use __vmalloc GFP_NOFS for fs-related allocations. In-Reply-To: References: <1422849594-15677-1-git-send-email-green@linuxhacker.ru> <20150202053708.GG4251@dastard> <20150202081115.GI4251@dastard> <54CF51C5.5050801@redhat.com> <20150203223350.GP6282@dastard> Message-ID: <20150205114459.GI12722@dastard> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Feb 04, 2015 at 02:13:29AM -0500, Oleg Drokin wrote: > 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 vmlist_lock and the list it protected went away in 3.10. Cheers, Dave. -- Dave Chinner david at fromorbit.com