[Top] [All Lists]

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

To: Arnd Bergmann <>
Subject: Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Steven Rostedt <>
Date: Sun, 16 Apr 2006 22:17:50 -0400 (EDT)
Cc: Paul Mackerras <>, Nick Piggin <>, LKML <>, Andrew Morton <>, Linus Torvalds <>, Ingo Molnar <>, Thomas Gleixner <>, Andi Kleen <>, Martin Mares <>,,,,, Chris Zankel <>, Marc Gauthier <>, Joe Taylor <>, David Mosberger-Tang <>,,,,,,,,,,,,,
In-reply-to: <>
Original-recipient: rfc822;
References: <1145049535.1336.128.camel@localhost.localdomain> <> <1145234750.27828.8.camel@localhost.localdomain> <>
On Mon, 17 Apr 2006, Arnd Bergmann wrote:

> Am Monday 17 April 2006 02:45 schrieb Steven Rostedt:
> > > - does not work in real mode, so percpu data can't be used
> > >   inside exception handlers on some architectures.
> >
> > This is probably a big issue.  I believe interrupt context in hrtimers
> > uses per_cpu variables.
> If it's just about hrtimers, it should be harmless, since they
> are run in softirq context. Even regular interrupt handlers are
> always called with paging enabled, otherwise you could not
> have them im modules.

Ah, you're right. You said exceptions, I'm thinking interrupts.  I was a
little confused why it wouldn't work.

> > > - memory consumption is rather high when PAGE_SIZE is large
> >
> > That's also something that I'm trying to solve.  To use the least amount
> > of memory and still have the performance.
> >
> > Now, I've also thought about allocating per_cpu and when a module is
> > loaded, reallocate more memory and copy it again.  Use something like
> > the kstopmachine to sync the system so that the CPUS don't update any
> > per_cpu variables while this is happening, so that things can't get out
> > of sync.
> I guess this breaks if someone holds a pointer to a per-cpu variable
> while a module gets loaded.

Argh, good point, I didn't think about that.  Hmm, this solution is
looking harder and harder.  Darn, I was really hoping this could be a
little better in space savings and robustness. It's starting to seem
clearer that Rusty's little hack, may be the best solution.

If that's the case, I can at least take comfort in knowing that the time I
spent on this is documented in LKML archives, and perhaps can keep others
from spending the time too.  That said, I haven't quite given up, and may
spend a couple more sleepless nights pondering this.

-- Steve

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