Re: [PATCH 3/4] Add SLAB allocator understanding.

[Jan Kiszka <jan.kiszka@siemens.com>]

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
>> <kieranbingham@gmail.com> 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