From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264261AbTDKF3t (for ); Fri, 11 Apr 2003 01:29:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264262AbTDKF3t (for ); Fri, 11 Apr 2003 01:29:49 -0400 Received: from palrel12.hp.com ([156.153.255.237]:1164 "EHLO palrel12.hp.com") by vger.kernel.org with ESMTP id S264261AbTDKF3s (for ); Fri, 11 Apr 2003 01:29:48 -0400 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16022.21891.554860.506152@napali.hpl.hp.com> Date: Thu, 10 Apr 2003 22:41:23 -0700 To: "Randy.Dunlap" Cc: , , , Subject: Re: proc_misc.c bug In-Reply-To: <32880.4.64.197.106.1050037303.squirrel@webmail.osdl.org> References: <200304102202.h3AM2YH3021747@napali.hpl.hp.com> <1050011057.12930.134.camel@dhcp22.swansea.linux.org.uk> <20030410154902.32f48f9c.rddunlap@osdl.org> <32880.4.64.197.106.1050037303.squirrel@webmail.osdl.org> X-Mailer: VM 7.07 under Emacs 21.2.1 Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >>>>> On Thu, 10 Apr 2003 22:01:43 -0700 (PDT), "Randy.Dunlap" said: Randy> OK, I've looked at it and concluded that it's not bad the way Randy> it is (after David's patch is applied). However, that really Randy> depends on whether the static NR_CPUS is well-tuned or not. Randy> If it's not tuned, then modifying the output to use the Randy> iterative seq_file methods would make sense. But if it's not Randy> tuned, someone is (usually) wasting lots of memory anyway. Randy> [snip...] Randy> Does someone want to disagree now? go ahead...i'm listening. Randy> Maybe the reason to modify it is that NR_CPUS is not a good Randy> approximation/hint/clue. Wouldn't the kmalloc() likely fail in fragmented conditions? Also, I'm wondering whether there is such a thing as "well-tuned" in this case. For example, in the extreme case of the SGI SN2 machine, each CPU could in theory have up to 256 interrupt sources (OK, perhaps it's only 256 interrupts per 2 CPUs, but it's still a lot of interrupts to go around ;-). OTOH, most ia64 machines out there have less than 256 interrupt per _system_. That's a large variation. --david