lkml.org 
[lkml]   [2009]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/6] INIT: Limit the number of per cpu calibration bootup messages


Cyrill Gorcunov wrote:
> On Tue, Nov 17, 2009 at 08:29:28AM -0800, David Miller wrote:
>> From: Cyrill Gorcunov <gorcunov@gmail.com>
>> Date: Tue, 17 Nov 2009 18:59:46 +0300
>>
>>> Perhaps for other archs like SPARC64, where as you said no need to
>>> remember boot cpu id at all, we should define some __weak per-kernel
>>> global helper which would return 0 and every arch would implement
>>> own helper boot_cpu_id().
>> On many of my machines none of my cpus are numbered "0", so that
>> wouldn't be a legitimate implementation on sparc64.
>>
>> I see no reason for a platform the be required to remember the boot
>> cpu ID, there is nothing special about that processor generically.
>
> I fear we still need it and it's special due to code structure at
> least. For SMP compiled kernel say callin() do change its behaviour
> depending on which cpu it's called.
>
> Also iy seems a differ techhique used to find out on which cpu
> the code is running: there is smp_processor_id() == 0 and raw version
> and boot_cpu_id and cpu == 0, so having one general boot_cpu_id() would
> be more clear (though we will need to clean code up then :)
>
> So plain hard_smp_processor_id() wouldn't help since it doesn't
> say if this is a boot cpu or not.
>
>> And if we do need it generically, it's available there as
>> hard_smp_processor_id() when start_kernel() is called. So init/main.c
>> could remember that value in an __initdata annotated static variable.
>>
>> But just using a boolean for this "did I print the bogomips message
>> already?" thing seems more than sufficient.
>>
>
> Yes. As I see Mike already pick it up. Thanks David!
>
> -- Cyrill

I'd like to say that, but Peter wanted it to become an inlined function
return value, and there are too many references in too many arches to
a scalar value, so that moves it out of the scope of this patch set.

Thanks,
Mike


\
 
 \ /
  Last update: 2009-11-17 18:53    [W:0.067 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site