[Top] [All Lists]

Re: [PATCH 00/05] robust per_cpu allocation for modules

To: Nick Piggin <>
Subject: Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Steven Rostedt <>
Date: Tue, 18 Apr 2006 08:47:57 -0400
Cc: Ravikiran G Thirumalai <>, Christoph Lameter <>, LKML <>, Andrew Morton <>, Linus Torvalds <>, Ingo Molnar <>, Thomas Gleixner <>, Andi Kleen <>, Martin Mares <>,,,, Chris Zankel <>, Marc Gauthier <>, Joe Taylor <>,,,,,,,,,,,,,
In-reply-to: <>
Original-recipient: rfc822;
References: <1145049535.1336.128.camel@localhost.localdomain> <> <> <20060417220238.GD3945@localhost.localdomain> <> <>
[Removed from CC and
because I keep getting "unknown user" bounces from them]

On Tue, 2006-04-18 at 16:42 +1000, Nick Piggin wrote:
> Steven Rostedt wrote:
> > Understood, but I'm going to start looking in the way Rusty and Arnd
> > suggested with the vmalloc approach. This would allow for saving of
> > memory and dynamic allocation of module memory making it more robust. And
> > all this without that evil extra indirection!
> Remember that this approach could effectively just move the indirection to
> the TLB / page tables (well, I say "moves" because large kernel mappings
> are effectively free compared with 4K mappings).

Yeah, I thought about the paging latencies when it was first mentioned.
And this is something that's going to be very hard to know the impact,
because it will be different on every system.

> So be careful about coding up a large amount of work before unleashing it:
> I doubt you'll be able to find a solution that doesn't involve tradeoffs
> somewhere (but wohoo if you can).

OK, but as I mentioned that this is now more of a side project, so a
month of work is not really going to be a month of work ;)  I'll first
try to get something that just "works" and then post an RFC PATCH set,
to get more ideas.  Since obviously there's a lot of people out there
that know their systems much better than I do ;)


-- Steve

<Prev in Thread] Current Thread [Next in Thread>