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).
> 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!
John Hawkes
|