Mikael Pettersson <[EMAIL PROTECTED]> wrote:
>
> In addition, there is one unresolved issue:
> - A counter's value is represented by a 64-bit software sum,
> a 32-bit start value containing the HW counter's value at the
> start of the current time slice, and the current HW counter's value
> (now). The actual value is computed as sum + (now - start).
> This is reflected in the mmap()ed state, which contains a variable-
> length { u32 map; u32 start; u64 sum; } pmc[] array.
> This layout is very cache-efficient on current 32 and 64-bit CPUs,
> but there is a _possible_ concern that it won't do on 10+ GHz CPUs.
> So the question is, should we change it to use 64-bit start values
> already now (and take more cache misses), or should that wait a few
> years until it becomes a necessity (causing ABI change issues)?
I'd be inclined to make the change now, personally. ABI changes are a pain
for everyone.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
