Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 9 Jun 2015 11:55:22 -0700 | Subject | Re: [PATCH v2 3/4] x86, mwaitt: introduce mwaix delay with a configurable timer |
| |
On Tue, Jun 9, 2015 at 11:43 AM, Borislav Petkov <bp@suse.de> 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@mit.edu
> >> > 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
| |