[PATCH 00/05] robust per_cpu allocation for modules
Steven Rostedt
rostedt at goodmis.org
Mon Apr 17 12:17:50 EST 2006
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
More information about the Linuxppc-dev
mailing list