[lkml]   [2003]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Make prof_counter use per-cpu areas patch 1/4 -- x86 arch
Ravikiran G Thirumalai <> wrote:
> Even cpu_possible does not seem to be setup this early. Seems like
> reinitialisation of prof_counter/prof_multiplier et al is redundant.
> Here's a newer patch which removes this initialisation at smp_boot_cpus.
> Works fine for me (tested same on a 4 way with difft profiling multipliers..
> LOC interrupts seem to fire at the right intervals).

Things still look a bit fishy to me.

In apic.c:

int prof_multiplier[NR_CPUS] = { 1, };
int prof_old_multiplier[NR_CPUS] = { 1, };
DEFINE_PER_CPU(int, prof_counter) = 1;

This means that all the prof_counter values are set to 1, but the multiplier
arrays have 1 in the zeroeth entry, and zero in the remaining entries.

The zero multipliers remain in place until someone runs

One approach would be to initialise all members:

int prof_multiplier[NR_CPUS] = { [ 0 ... NR_CPUS-1 ] = 1 };

But I think it would be better to put the multipliers into per-cpu memory as
well. Something like:

struct profiling_info {
int multiplier;
int old_multiplier;
int counter;

DEFINE_PER_CPU(struct profiling_info, profiling_info) = {1, 1, 1};


Also bits and pieces of the profiling code seem to be randomly splattered all
over the place. Consolidating it all into the one .c file would be nice.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.036 / U:1.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site