Re: [PATCH v2 3/4] x86, mwaitt: introduce mwaix delay with a configurable timer

[Andy Lutomirski]

On Tue, Jun 9, 2015 at 11:43 AM, Borislav Petkov <bp@xxxxxxx> wrote:
> On Tue, Jun 09, 2015 at 10:55:15AM -0700, Andy Lutomirski wrote:
>> When I looked at the rdtsc ordering a couple years ago, I thought
>> about what it meant for rdtsc to be properly ordered.  I decided that
>> proper rdtsc ordering meant that no one should ever be able to tell if
>> rdtsc ends up reordered.  Concretely, I think that rdtsc should be
>> ordered like an x86 load from a shared memory location.  The manuals
>> are vague but, after a decent amount of experimentation,
>> rdtsc_barrier(); rdtsc() seems to achieve that on all CPUs.  With the
>> barrier, the rdtsc won't happen before a prior load in the same
>> thread, and no CPU seems to ever execute rdtsc after a subsequent
>> memory access.
>
> That sounds weak to me. I think we will need some enlightenment from hw
> people here before we go assume stuff.

For your reading pleasure:

https://lkml.kernel.org/g/80b43d57d15f7b141799a7634274ee3bfe5a5855.1302137785.git.luto@xxxxxxx

>
>> > By virtue of the address dependency?
>>
>> No, it's just that CPUs seem to work this way.
>
> Err, that sounds funny. And it must be the data dependency forcing the
> RDTSC to execute in order in that case.

Apparently not -- see above.  I tried it with an explicit data
dependency, which amused Linus, but in the end everyone agreed that
rdtsc_barrier(); rdtsc() was the right way to read the time.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/