Re: [PATCH v4 0/2] Move x86_cpu_to_apicid to the __read_mostly section

[Vlad Zolotarov <vlad@scalemp.com>]

On Wednesday 23 May 2012 12:16:29 Vlad Zolotarov wrote:
> On Tuesday, May 22, 2012 18:55:41 Vlad Zolotarov wrote:
> > > > I have no fundamental prefer to either approach, but the
> > > > direction taken should be justified explicitly, with numbers,
> > > > arguments, etc. - also a short blurb somewhere in the headers
> > > > that explains when they should be used, so that others can be
> > > > aware of vSMP's special needs here.
> > > 
> > > I.e. *numbers* are needed: roughly how many percpu variables in
> > > a defconfig of one type versus the other type. This settles the
> > > question whether we want to identify read-mostly or
> > > write-frequently variables, to address this particular problem
> > > ...
> 
> Ingo, here is the proposal to the patch (series) description:
> 
> ----------------------------------------------------------------------------
> -------------------- Added "read-mostly" qualifier to the following
> variables in smp.h: - cpu_sibling_map
>  - cpu_core_map
>  - cpu_llc_shared_map
>  - cpu_llc_id
>  - cpu_number
>  - x86_cpu_to_apicid
>  - x86_bios_cpu_apicid
>  - x86_cpu_to_logical_apicid
> 
> As long as all the variables above are only written during the
> initialization, this change is meant to prevent the false sharing. More
> specifically, on vSMP Foundation platform x86_cpu_to_apicid shared the same
> internode_cache_line with frequently written lapic_events.
> 
> From the analysis of the first 33 per_cpu variables  out of 219 (memories
> they describe, to be more specific) the 8 have read_mostly nature
> (tlb_vector_offset, cpu_loops_per_jiffy, xen_debug_irq, etc.) and 25 are
> frequently written (irq_stack_union, gdt_page, exception_stacks, idt_desc,
> etc.). Assuming that the spread of the rest of the per_cpu variables is
> similar, identifying the read mostly memories will make more sense in terms
> of long-term code maintenance comparing to identifying frequently written
> memories.
> ----------------------------------------------------------------------------
> -----------------------
> 
> Pls., tell me if the above looks satisfactory to u in light of all your
> previous remarks.
> 
> If yes - I'll respin the series with the description above.

Ingo, sorry for bothering. Could u, pls., tell if the above description is ok? We'd
like to move on with this patch series.

thanks in advance,
vlad

> 
> thanks,
> vlad
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/