Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 30 Apr 2001 02:16:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 30 Apr 2001 02:16:30 -0400 Received: from www.wen-online.de ([212.223.88.39]:42258 "EHLO wen-online.de") by vger.kernel.org with ESMTP id ; Mon, 30 Apr 2001 02:16:10 -0400 Date: Mon, 30 Apr 2001 08:15:43 +0200 (CEST) From: Mike Galbraith X-X-Sender: To: Frank de Lange cc: linux-kernel Subject: Re: Severe trashing in 2.4.4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 29 Apr 2001, Alexander Viro wrote: > On Sun, 29 Apr 2001, Frank de Lange wrote: > > > On Sun, Apr 29, 2001 at 12:27:29PM -0400, Alexander Viro wrote: > > > What about /proc/slabinfo? Notice that 2.4.4 (and couple of the 2.4.4-pre) > > > has a bug in prune_icache() that makes it underestimate the amount of > > > freeable inodes. > > > > Gotcha, wrt. slabinfo. Seems 2.4.4 (at least on my box) only knows how to > > allocate skbuff_head_cache entries, not how to free them. Here's the last > > /proc/slabinfo entry before I sysRQ'd the box: > > > skbuff_head_cache 341136 341136 160 14214 14214 1 : 252 126 > > size-2048 66338 66338 2048 33169 33169 1 : 60 30 > > Hmm... I'd say that you also have a leak in kmalloc()'ed stuff - something > in 1K--2K range. From your logs it looks like the thing never shrinks and > grows prettu fast... If it turns out to be difficult to track down, holler and I'll expedite updating my IKD tree to 2.4.4. -Mike (memleak maintenance weenie) - 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/