Messages in this thread | | | Subject | Re: [RFC] [PATCH] Disable TSCs on CONFIG_MULTIQUAD | From | john stultz <> | Date | 29 May 2002 18:36:40 -0700 |
| |
> Not all the other places are "there is no TSC" most of them deal with > the ability to use a TSC. There are other setups where TSC exists but > isnt usable so distinguishing matters
Martin's clarification aside, I'll agree that distinguishing between no TSC and unsynced TSCs is reasonable. There might be kernel code paths that cannot migrate between cpus, use the TSC for timing, and do not save the value in global structures. So in that case, reading the non synced TSC would be safe and disabling TSCs totally w/ multiquad might be a touch rash. I just haven't actually looked to see if such cases exist. Are there other reasons unsynced TSCs might still be useful?
> Also there is one case where TSC that doesn't work matters specifically > - you want to turn off RDTSC access from user space to avoid user space > tools having little accidents
I was hoping that would fall into place when the X86_FEATURE_TSC bit of boot_cpu_data.x86_capability (aka: cpu_has_tsc) was disabled. I'll double check however, just to be sure.
Thanks again. -john
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |