lkml.org 
[lkml]   [2002]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] [PATCH] Disable TSCs on CONFIG_MULTIQUAD
From
Date
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:26    [W:0.062 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site