Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751836AbbHMFwq (ORCPT ); Thu, 13 Aug 2015 01:52:46 -0400 Received: from mail-io0-f180.google.com ([209.85.223.180]:36336 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750908AbbHMFwp (ORCPT ); Thu, 13 Aug 2015 01:52:45 -0400 MIME-Version: 1.0 In-Reply-To: <20150812210027.88dfcf90.akpm@linux-foundation.org> References: <20150812210027.88dfcf90.akpm@linux-foundation.org> Date: Wed, 12 Aug 2015 22:52:44 -0700 X-Google-Sender-Auth: bMfGN1LZJk8cgo5e4I7FAtuxxkI Message-ID: Subject: Re: get_vmalloc_info() and /proc/meminfo insanely expensive From: Linus Torvalds To: Andrew Morton Cc: Joonsoo Kim , Al Viro , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1023 Lines: 24 On Wed, Aug 12, 2015 at 9:00 PM, Andrew Morton wrote: > > Do your /proc/meminfo vmalloc numbers actually change during that build? > Mine don't. Perhaps we can cache the most recent vmalloc_info and > invalidate that cache whenever someone does a vmalloc/vfree/etc. Sure, that works too. Looking at that mm/vmalloc.c file, the locking is pretty odd. It looks pretty strange in setup_vmalloc_vm(), for example. If that newly allocated "va" that we haven't even exposed to anybody yet has its address or size changed, we're screwed in so many ways. I get the feeling this file should be rewritten. But that's not going to happen. The "let's just cache the last value for one jiffy" seemed to be the minimal fixup to it. Linus -- 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/