Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932643AbWAFGfx (ORCPT ); Fri, 6 Jan 2006 01:35:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932644AbWAFGfx (ORCPT ); Fri, 6 Jan 2006 01:35:53 -0500 Received: from mf00.sitadelle.com ([212.94.174.67]:62519 "EHLO smtp.cegetel.net") by vger.kernel.org with ESMTP id S932643AbWAFGfx (ORCPT ); Fri, 6 Jan 2006 01:35:53 -0500 Message-ID: <43BE0FC3.7030602@cosmosbay.com> Date: Fri, 06 Jan 2006 07:35:47 +0100 From: Eric Dumazet User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: David Lang Cc: Andi Kleen , linux-kernel@vger.kernel.org Subject: Re: [PATCH] Shrinks sizeof(files_struct) and better layout References: <20051108185349.6e86cec3.akpm@osdl.org> <437226B1.4040901@cosmosbay.com> <20051109220742.067c5f3a.akpm@osdl.org> <4373698F.9010608@cosmosbay.com> <43BB1178.7020409@cosmosbay.com> <43BBADD5.3070706@cosmosbay.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1502 Lines: 35 David Lang a ?crit : > On Wed, 4 Jan 2006, Eric Dumazet wrote: >> Andi Kleen a ?crit : >>> Eric Dumazet writes: >>>> 1) Reduces the size of (struct fdtable) to exactly 64 bytes on 32bits >>>> platforms, lowering kmalloc() allocated space by 50%. >>> >>> It should be probably a kmem_cache_alloc() instead of a kmalloc >>> in the first place anyways. This would reduce fragmentation. >> >> Well in theory yes, if you really expect thousand of tasks running... >> But for most machines, number of concurrent tasks is < 200, and using >> a special cache for this is not a win. > > is it enough of a win on machines with thousands of concurrent tasks > that it would be a useful config option? Well..., not if NR_CPUS is big too. (We just saw a thread on lkml about raising NR_CPUS to 1024 on ia64). On a 1024 CPUS machine, a kmem cache could use at least 1 MB for its internal structures, plus 1024 pages (PAGE_SIZE) for holding the caches (one cache per CPU), if you assume at least one task was created on behalf each cpu. if PAGE_SIZE is 64KB, you end up with 65 MB of ram for the cache. Even with 100.000 tasks running on the machine, its not a win. slab caches are very complex machinery that consume O(NR_CPUS) ram. Eric - 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/