From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6133 invoked by alias); 2 Feb 2016 07:22:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 6118 invoked by uid 89); 2 Feb 2016 07:22:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=Corporate, siemens, Hx-languages-length:1646, Siemens X-HELO: thoth.sbs.de Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 02 Feb 2016 07:22:31 +0000 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id u127MQOf007582 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 2 Feb 2016 08:22:26 +0100 Received: from md1f2u6c.ww002.siemens.net ([139.22.36.247]) by mail1.siemens.de (8.15.1/8.15.1) with SMTP id u127MP9W014582; Tue, 2 Feb 2016 08:22:25 +0100 Subject: Re: [PATCH 3/4] Add SLAB allocator understanding. To: Ales Novak , Doug Evans References: <1454276692-7119-1-git-send-email-alnovak@suse.cz> <1454276692-7119-4-git-send-email-alnovak@suse.cz> <56AF5BC8.4010509@gmail.com> Cc: Kieran Bingham , gdb-patches , Vlastimil Babka From: Jan Kiszka Message-ID: <56B05931.9050705@siemens.com> Date: Tue, 02 Feb 2016 07:22:00 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00039.txt.bz2 On 2016-02-02 03:05, Ales Novak wrote: > On 2016-2-1 23:29, Doug Evans wrote: > >> On Mon, Feb 1, 2016 at 5:21 AM, Kieran Bingham >> wrote: >>> This is interesting work! >>> >>> I had been discussing how we might achieve managing this with Jan @ >>> FOSDEM yesterday. >>> >>> I believe a python implementation of this could be possible, and then >>> this code can live in the Kernel, and be split across architecture >>> specific layers where necessary to implement handling userspace >>> application boundaries from the Kernel Awareness. >> >> Keeping application specific code with the application instead of gdb >> is definitely a worthy goal. >> [one can quibble over whether linux is an application of course, >> but that's just terminology] > > Yeah, you're right. Yet if we're talking about the SLAB in particular - > considering with how many objects simultaneously has this subsystem to > cope, I'm afraid that adding any extra overhead (e.g. the Pythonish) > will be just painful. > > It's a pitty that gdb cannot be extended dynamically, afaics. First, don't be too sceptical before some has tried this. And then there are still options for optimizations, either on the language side (C extension to our Python modules, also in-kernel maintained) or more efficient interfaces for gdb's Python API. It's definitely worth exploring this first before adding Linux kernel release specific things to gdb, which is going to be even more painful to maintain. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux