Re: [2.6.28-rc6] oprofile: "opcontrol --start" output two warnings

[KOSAKI Motohiro]

Hi

Thank you for good comment.

> KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> writes:
> >
> > Index: b/arch/x86/oprofile/op_model_p4.c
> > ===================================================================
> > --- a/arch/x86/oprofile/op_model_p4.c	2008-11-24 06:20:04.000000000 +0900
> > +++ b/arch/x86/oprofile/op_model_p4.c	2008-11-24 06:29:09.000000000 +0900
> > @@ -399,6 +399,8 @@ static void p4_fill_in_addresses(struct 
> >  	unsigned int i;
> >  	unsigned int addr, cccraddr, stag;
> >  
> > +	get_cpu();
> 
> The whole thing seems broken anyways because the only caller of
> fill_in_addresses only assigns to CPU 0 and fill_in_addresses only
> runs on some CPU. So I guess the stagger handling could be just
> removed because it's useless.

hm,
if so, I think get_stagger() is a bit strange.
it depend on caller cpu. then if PREEMPT=Y, it return radom result.

I'm not sure about oprofile design.
but if you are right, I think p4_fill_in_addresses shoudn't use smp_processor_id().

Am I missing any point?


	static unsigned int get_stagger(void)
	{
	#ifdef CONFIG_SMP
	        int cpu = smp_processor_id();
	        return (cpu != first_cpu(per_cpu(cpu_sibling_map, cpu)));
	#endif
	        return 0;
	}



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