Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755929AbYAGUMz (ORCPT ); Mon, 7 Jan 2008 15:12:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753259AbYAGUMq (ORCPT ); Mon, 7 Jan 2008 15:12:46 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1]:58026 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752940AbYAGUMq (ORCPT ); Mon, 7 Jan 2008 15:12:46 -0500 Date: Mon, 7 Jan 2008 22:12:44 +0200 (EET) From: Pekka J Enberg To: Christoph Lameter cc: Matt Mackall , Ingo Molnar , Linus Torvalds , Hugh Dickins , Andi Kleen , Peter Zijlstra , Linux Kernel Mailing List , zanussi@us.ibm.com Subject: Re: [PATCH] procfs: provide slub's /proc/slabinfo In-Reply-To: Message-ID: References: <84144f020801021109v78e06c6k10d26af0e330fc85@mail.gmail.com> <1199314218.4497.109.camel@cinder.waste.org> <20080103085239.GA10813@elte.hu> <1199378818.8274.25.camel@cinder.waste.org> <1199419890.4608.77.camel@cinder.waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1745 Lines: 41 Hi Christoph, On Sat, 5 Jan 2008, Pekka J Enberg wrote: > > So, I have this silly memory profiler derived from the kleak patches by > > the relayfs people and would love to try it out on an embedded workload > > where SLUB memory footprint is terrible. Any suggestions? On Sat, 5 Jan 2008, Christoph Lameter wrote: > Good idea. But have you tried to look at slabinfo? > > Try to run > > slabinfo -t > > which will calculate the allocation overhead of the currently allocated > objects in all slab caches. Oh, I didn't know about that. It's great for looking at the current memory footprint but not really suitable if you want to analyze allocation/free patterns. And I think we need to look at the patterns to figure out *where* and *why* SLOB is better than SLUB and whether that can be fixed in SLUB or the callers. For example, while it's obviously true that SLUB has much higher internal fragmentation for kmalloc() than SLOB, it doesn't matter as much if the allocations are short-lived. I don't think you can extend the current SLUB debug mechanism to provide that but rather "kmalloc accounting" is needed. The problem with my patch, though, is that due to relayfs I cannot capture events unless userspace is ready to read them which is why I am missing all the data from boot (I think systemtap has this same limitation?). So we need something like what Matt has except that it needs to keep track of every *event* and userspace must be able to access them. Pekka -- 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/