From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751456AbWGMONs (ORCPT ); Thu, 13 Jul 2006 10:13:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751488AbWGMONs (ORCPT ); Thu, 13 Jul 2006 10:13:48 -0400 Received: from hellhawk.shadowen.org ([80.68.90.175]:1548 "EHLO hellhawk.shadowen.org") by vger.kernel.org with ESMTP id S1751456AbWGMONr (ORCPT ); Thu, 13 Jul 2006 10:13:47 -0400 Message-ID: <44B654EA.3030301@shadowen.org> Date: Thu, 13 Jul 2006 15:12:58 +0100 From: Andy Whitcroft User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: Martin Bligh CC: Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: 2.6.18-rc1-git4 and 2.6.18-rc1-mm1 OOM's on boot References: <44B528F4.6080409@google.com> <20060712181636.d7cbbb99.akpm@osdl.org> <44B5A0DD.9070200@google.com> In-Reply-To: <44B5A0DD.9070200@google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Martin Bligh wrote: > Andrew Morton wrote: >> On Wed, 12 Jul 2006 09:53:08 -0700 >> Martin Bligh wrote: >> >> >>> -git3 was fine >>> (bootlog for git3: http://test.kernel.org/abat/40748/debug/console.log) >>> >>> -mm1 has the same issue >>> >>> Slightly different manifestations across 2 boots >>> >>> http://test.kernel.org/abat/40760/debug/console.log >>> http://test.kernel.org/abat/40837/debug/console.log >> >> >> [] out_of_memory+0x29/0xf6 >> [] __alloc_pages+0x1ed/0x276 >> [] kmem_getpages+0x63/0xc1 >> [] cache_grow+0xaa/0x139 >> [] cache_alloc_refill+0x17b/0x1c0 >> [] __kmalloc+0x83/0x93 >> [] alloc_fd_array+0x19/0x24 >> [] alloc_fdtable+0xb2/0xef >> [] expand_fdtable+0x20/0x7d >> [] expand_files+0x45/0x50 >> [] locate_fd+0x70/0x8e >> [] dupfd+0x29/0x61 >> [] sys_dup+0x1b/0x23 >> [] syscall_call+0x7/0xb >> >> I suspect that's because I had me a little mistake. >> >> --- a/fs/file.c~alloc_fdtable-expansion-fix >> +++ a/fs/file.c >> @@ -240,7 +240,7 @@ static struct fdtable *alloc_fdtable(int >> if (!fdt) >> goto out; >> >> - nfds = max_t(int, 8 * L1_CACHE_BYTES, roundup_pow_of_two(nfds)); >> + nfds = max_t(int, 8 * L1_CACHE_BYTES, roundup_pow_of_two(nr + 1)); >> if (nfds > NR_OPEN) >> nfds = NR_OPEN; >> >> _ >> > > Thanks, that was affecting several machines. > > Andy, any chance we can do an across-all-machines run of that one on top > of -mm1? Thanks, > > M. Yep, I've run this with badari's fix as a set across the whole family. I did all dbenchall runs for now as this example is showing on that and badari's is triggered same. If there is any measure of success there I'll throw in the externals too. -apw