Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755321Ab1FOWTP (ORCPT ); Wed, 15 Jun 2011 18:19:15 -0400 Received: from mga02.intel.com ([134.134.136.20]:37021 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752362Ab1FOWTN (ORCPT ); Wed, 15 Jun 2011 18:19:13 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.65,371,1304319600"; d="scan'208";a="15291343" Message-ID: <4DF92FE1.5010208@linux.intel.com> Date: Wed, 15 Jun 2011 15:19:13 -0700 From: Andi Kleen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Linus Torvalds CC: Peter Zijlstra , Tim Chen , Shaohua Li , Andrew Morton , Hugh Dickins , KOSAKI Motohiro , Benjamin Herrenschmidt , David Miller , Martin Schwidefsky , Russell King , Paul Mundt , Jeff Dike , Richard Weinberger , "Luck, Tony" , KAMEZAWA Hiroyuki , Mel Gorman , Nick Piggin , Namhyung Kim , "Shi, Alex" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "Rafael J. Wysocki" Subject: Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex References: <1308097798.17300.142.camel@schen9-DESK> <1308101214.15392.151.camel@sli10-conroe> <1308138750.15315.62.camel@twins> <20110615161827.GA11769@tassilo.jf.intel.com> <1308156337.2171.23.camel@laptop> <1308163398.17300.147.camel@schen9-DESK> <1308169937.15315.88.camel@twins> <4DF91CB9.5080504@linux.intel.com> <1308172336.17300.177.camel@schen9-DESK> <1308173849.15315.91.camel@twins> <87ea4bd7-8b16-4b24-8fcb-d8e9b6f421ec@email.android.com> In-Reply-To: <87ea4bd7-8b16-4b24-8fcb-d8e9b6f421ec@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 799 Lines: 21 > Yeah, I think it's ridiculous to say that glibc is not doing something stupid and that it's a problem with kernel interfaces. > > Do the proc file parsing once and cache the result in a static variable. Doing it over and over again is just crazy. > > Adding new system calls because glibc is crazy is insane. Caching doesn't help because the library gets reinitialized in every child (it may already do caching, not fully sure for this; it does it for other sysconfs at least) I don't think glibc is crazy in this. It has no other choice. -Andi -- 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/