>
> From: Frank Hofmann - Sun Germany Technical Solution Center - Munich
> <Frank.Hofmann@xxxxxxxxxxxxxxx>
> To: <lockmeter@xxxxxxxxxxx>
> <...snip...>
> > In lockmeter.c, there are several points which prevent that it
> > compiles on non-IA32:
> >
> > 1. the use of "cpucount".
> <...snip...>
> > Replacing this by the arch-independent global "smp_num_cpus" works.
>
> Yes. Thank you.
>
> > 2. Same for "cpu_hz". This is only used currently to fill in a field
> > in the lockstat info struct. I don't know an arch-independent way
> > to get this but it's not required for working lockstat and so I've
> > just removed it for the moment.
>
> cpu_hz is used by the user program "lockstat" to translate the raw
> "ticks" count into user-meaningful time. For x86 the "ticks" are cpu
> cycles, so cpu_hz allows "lockstat" to convert to microseconds or
> milliseconds for display purposes. I suppose to make this more
> multi-platform, there should be abstracted macros for obtaining some
> low-level raw time "ticks" (for x86 that macro expands to a call to
> get_cycles()) and for defining some divisor that converts these "ticks"
> into microseconds.
>
> Of course, a real multi-platform solution would have a
> include/linux/lockmeter.h containing the bulk of the
> architecture-independent code, and a handful of architecture-specific
> include/XYZ/lockmeter.h files which contain the various macro
> definitions that lockmeter.c and include/linux/lockmeter.h use.
>
> Anyway, you can remove the reference to cpu_hz in order to get a Sparc
> lockmeter.c to build, but "lockstat" isn't going to display correct
> numbers (and might even divide-by-zero if you don't initialize the
> kernel-to-user lstat_user_request_t "cycleval" field to a nonzero
> value).
I'll check for a way to get the CPU clock frequency on SPARC. On my SS10,
the reported BogoMIPS value corresponds to the CPU freq in MHz - this may
be accidental, I'm going to look deeper into this code.
I believe for any kind of statistics interface a way to get the CPU freq
would be very useful. Still, to my knowledge the kernel does not have a
generic interface for this.
>
> > 3. The following assembler code:
> and
> > 4. The following assembler code:
>
> I'll work on abstracting these. Thank you.
>
> > - lockmeter.h: I'm not sure about the LSTAT_RA macro.
> > - endianness issues: Have not yet been able to check for this.
>
> Oh, true.
>
> I'm afraid I was being rather x86-centric. Thanks for your suggestions!
Thank you for providing this code in the first place ;-)
Still, I must have made some errors (or left out something) because my
adaptions prevent the kernel from booting. I've made sure that it is
the lockmetering stuff because if I build a kernel with nothing changed
but CONFIG_LOCKMETER unset it works well.
With lockmeter, initial loading stops after the message "Now booting the
kernel", so problems must start in a very early phase. I've not yet tried
to add printk()'s to narrow down where it blocks.
A question aside: What's EXPORT_SYMBOL actually doing, and do I need to
export the lockmetering _spin_lock_ ... symbols for it to work ? I had
to leave this out because the kernel did not want to compile - I believe
there's a problem with #define's.
As soon as I have either a working lockmeter on sparc-linux or the reason
why the kernel blocks so early in the initialization phase, I will update
the list.
Bye,
Frank
|