[Top] [All Lists]

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

To: Steven Rostedt <>
Subject: Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Arnd Bergmann <>
Date: Mon, 17 Apr 2006 04:07:23 +0200
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: <1145234750.27828.8.camel@localhost.localdomain>
Original-recipient: rfc822;
References: <1145049535.1336.128.camel@localhost.localdomain> <> <1145234750.27828.8.camel@localhost.localdomain>
User-agent: KMail/1.9.1
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.

> > - 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.

        Arnd <><

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