Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750949AbVKKRp2 (ORCPT ); Fri, 11 Nov 2005 12:45:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750959AbVKKRp2 (ORCPT ); Fri, 11 Nov 2005 12:45:28 -0500 Received: from omx2-ext.sgi.com ([192.48.171.19]:16077 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S1750922AbVKKRp2 (ORCPT ); Fri, 11 Nov 2005 12:45:28 -0500 Date: Fri, 11 Nov 2005 09:43:22 -0800 (PST) From: Christoph Lameter To: Con Kolivas cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, alokk@calsoftinc.com Subject: Re: [RFC, PATCH] Slab counter troubles with swap prefetch? In-Reply-To: <200511111450.07396.kernel@kolivas.org> Message-ID: References: <200511111007.12872.kernel@kolivas.org> <200511111450.07396.kernel@kolivas.org> 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 Content-Length: 965 Lines: 21 On Fri, 11 Nov 2005, Con Kolivas wrote: > One last thing. Swap prefetch works off the accounting of total memory and is > only a single kernel thread rather than a thread per cpu or per pgdat unlike > kswapd. Currently it just cares about total slab data and total ram. > Depending on where this thread is scheduled (which node) your accounting > change will alter the behaviour of it. Does this affect the relevance of this > patch to you? Yes, if its a truly global value then we would not need the patch. But then the prefetch code would have to add up all the nr_slab field for all processors and use that result for comparison. If you do this in a node specific fashion then the problem comes up again. - 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/