[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100329031804.GA12788@Krystal>
Date: Sun, 28 Mar 2010 23:18:04 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Lai Jiangshan <laijs@...fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
akpm@...ux-foundation.org, Ingo Molnar <mingo@...e.hu>,
linux-kernel@...r.kernel.org, dipankar@...ibm.com,
josh@...htriplett.org, dvhltc@...ibm.com, niv@...ibm.com,
tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
Valdis.Kletnieks@...edu, dhowells@...hat.com,
eric.dumazet@...il.com, adobriyan@...il.com,
Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>
Subject: Re: [RFC patch] extable and module add object is static
* Lai Jiangshan (laijs@...fujitsu.com) wrote:
> Mathieu Desnoyers wrote:
> > +static int core_object_is_static(void *obj)
> > +{
> [...]
> > + if (addr >= (unsigned long)__per_cpu_start &&
> > + addr <= (unsigned long)__per_cpu_end)
> > + return 1;
>
> This may only correct for UP.
> You may need arch-special codes for SMP.
>
looking at include/linux/percpu.h:
#ifndef PERCPU_ENOUGH_ROOM
#define PERCPU_ENOUGH_ROOM \
(ALIGN(__per_cpu_end - __per_cpu_start, SMP_CACHE_BYTES) + \
PERCPU_MODULE_RESERVE)
#endif
I was under the impression that most architectures were keeping their per-cpu
data within the __per_cpu_start .. __per_cpu_end range. But I see that ia64
is the only one to redefine PERCPU_ENOUGH_ROOM. I'm not sure if it can be a
problem. Is that what you had in mind ?
(adding Tony and Fenghua in CC so they can confirm)
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists