Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753443AbbHWUxe (ORCPT ); Sun, 23 Aug 2015 16:53:34 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:35848 "EHLO mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751612AbbHWUxd (ORCPT ); Sun, 23 Aug 2015 16:53:33 -0400 From: Rasmus Villemoes To: Ingo Molnar 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 Organization: D03 References: <20150823060443.GA9882@gmail.com> <20150823064603.14050.qmail@ns.horizon.com> <20150823081750.GA28349@gmail.com> X-Hashcash: 1:20:150823:linux@horizon.com::74OY0bWTF6JJdNH2:000000000000000000000000000000000000000000000cnm X-Hashcash: 1:20:150823:rientjes@google.com::1aB/7FoDMAScqiqM:0000000000000000000000000000000000000000001N2T X-Hashcash: 1:20:150823:linux-kernel@vger.kernel.org::UITJar0R4wJ1Oo7d:0000000000000000000000000000000002D9t X-Hashcash: 1:20:150823:mingo@kernel.org::ASqES/1Ij1Oo194A:02jW9 X-Hashcash: 1:20:150823:dave@sr71.net::7b+4snVzzzVTET+H:00003pz+ X-Hashcash: 1:20:150823:torvalds@linux-foundation.org::25VyRHnuaVkyXrqu:000000000000000000000000000000003J77 X-Hashcash: 1:20:150823:linux-mm@kvack.org::CE9pFa9YOHPKu7c+:00000000000000000000000000000000000000000006P4N X-Hashcash: 1:20:150823:riel@redhat.com::PuIN88VZFuJHPj1B:006RAj X-Hashcash: 1:20:150823:peterz@infradead.org::B6VYp4pjX7edC7hV:000000000000000000000000000000000000000007Wai Date: Sun, 23 Aug 2015 22:53:28 +0200 In-Reply-To: <20150823081750.GA28349@gmail.com> (Ingo Molnar's message of "Sun, 23 Aug 2015 10:17:51 +0200") Message-ID: <87lhd1wwtz.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1513 Lines: 35 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? > ==============================> > 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. Rasmus -- 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/