Re: [PATCH] hugeltb: Mark hugelb_max_hstate __read_mostly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 15 Jun 2012 11:40:24 +0530
"Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote:

> Michal Hocko <mhocko@xxxxxxx> writes:
> 
> > On Thu 14-06-12 19:26:18, Aneesh Kumar K.V wrote:
> >> From: "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
> >> 
> >> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
> >> ---
> >>  include/linux/hugetlb.h |    2 +-
> >>  mm/hugetlb.c            |    2 +-
> >>  2 files changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> >> index 9650bb1..0f0877e 100644
> >> --- a/include/linux/hugetlb.h
> >> +++ b/include/linux/hugetlb.h
> >> @@ -23,7 +23,7 @@ struct hugepage_subpool {
> >>  };
> >>  
> >>  extern spinlock_t hugetlb_lock;
> >> -extern int hugetlb_max_hstate;
> >> +extern int hugetlb_max_hstate __read_mostly;
> >
> > It should be used only for definition
> >
> I looked at the rest of the source and found multiple place where we
> specify __read_mostly in extern.
> 
> arch/x86/kernel/cpu/perf_event.h extern struct x86_pmu x86_pmu __read_mostly;

We have had one situation in the past where the lack of a section
annotation on a declaration caused an architecture (arm?) to fail to
build.  iirc the compiler emitted some short-mode relative-addressed
opcode to reference the variable, but when the linker came along to
resolve the offset it discovered that it exceeded the short-mode
addressing range, because that variable was in a section which landed
far away from .data.

That's only happened once, and that architecture might have changed,
and we're missing the section annotation on many variables anyway, so
I'd be inclined to just leave it off - if we ever hit significant
problems with this, we have a lot of work to do.

Also, we currently have no automated way of keeping the annotation on
the declaration and definition in sync.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]