Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753985AbbHXG6O (ORCPT ); Mon, 24 Aug 2015 02:58:14 -0400 Received: from mail-wi0-f176.google.com ([209.85.212.176]:37509 "EHLO mail-wi0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753943AbbHXG6N (ORCPT ); Mon, 24 Aug 2015 02:58:13 -0400 Date: Mon, 24 Aug 2015 08:58:09 +0200 From: Ingo Molnar To: Rasmus Villemoes Cc: George Spelvin , dave@sr71.net, linux-kernel@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, riel@redhat.com, rientjes@google.com, torvalds@linux-foundation.org Subject: Re: [PATCH 3/3 v3] mm/vmalloc: Cache the vmalloc memory info Message-ID: <20150824065809.GA13082@gmail.com> References: <20150823060443.GA9882@gmail.com> <20150823064603.14050.qmail@ns.horizon.com> <20150823081750.GA28349@gmail.com> <87lhd1wwtz.fsf@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lhd1wwtz.fsf@rasmusvillemoes.dk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3072 Lines: 76 * Rasmus Villemoes wrote: > On Sun, Aug 23 2015, Ingo Molnar wrote: > > > Ok, fair enough - so how about the attached approach instead, which > > uses a 64-bit generation counter to track changes to the vmalloc > > state. > > How does this invalidation approach compare to the jiffies approach? In > other words, how often does the vmalloc info actually change (or rather, > in this approximation, how often is vmap_area_lock taken)? In > particular, does it also solve the problem with git's test suite and > similar situations with lots of short-lived processes? The two approaches are pretty similar, and in a typical distro with typical workload vmalloc() is mostly a boot time affair. But vmalloc() can be used more often in certain corner cases - neither of the patches makes that in any way slower, just the optimization won't trigger that often. Since vmalloc() use is suboptimal for several reasons (it does not use large pages for kernel space allocations, etc.), this is all pretty OK IMHO. > > ==============================> > > From f9fd770e75e2edb4143f32ced0b53d7a77969c94 Mon Sep 17 00:00:00 2001 > > From: Ingo Molnar > > Date: Sat, 22 Aug 2015 12:28:01 +0200 > > Subject: [PATCH] mm/vmalloc: Cache the vmalloc memory info > > > > Linus reported that glibc (rather stupidly) reads /proc/meminfo > > for every sysinfo() call, > > Not quite: It is done by the two functions get_{av,}phys_pages > functions; and get_phys_pages is called (once per process) by glibc's > qsort implementation. In fact, sysinfo() is (at least part of) the cure, > not the disease. Whether qsort should care about the total amount of > memory is another discussion. > > Thanks, is the fixed up changelog below better? Ingo ===============> mm/vmalloc: Cache the vmalloc memory info Linus reported that for scripting-intense workloads such as the Git build, glibc's qsort will read /proc/meminfo for every process created (by way of get_phys_pages()), which causes the Git build to generate a surprising amount of kernel overhead. A fair chunk of the overhead is due to get_vmalloc_info() - which walks a potentially long list to do its statistics. Modify Linus's jiffies based patch to use generation counters to cache the vmalloc info: vmap_unlock() increases the generation counter, and the get_vmalloc_info() reads it and compares it against a cached generation counter. Also use a seqlock to make sure we always print a consistent set of vmalloc statistics. Reported-by: Linus Torvalds Cc: Andrew Morton Cc: Rik van Riel Cc: linux-mm@kvack.org Signed-off-by: Ingo Molnar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/