* Andy Lutomirski <l...@amacapital.net> wrote:
> On Wed, Jul 1, 2015 at 9:38 AM, Brown, Len <len.br...@intel.com> wrote:
>
> > BTW. I've had a discussion w/ LLNL about their needs, both for security and
> > performance. For security, as concluded by this thread, a white list is
> > the
> > only way to go. I'm thinking a bit-vector of allowed MSR offsets... For
> > performance, they absolutely can not afford a system call for every single
> > MSR
> > access.
>
> I'm surprised. On a sane kernel, a syscall is about 120 cycles. Just rdmsr
> to
> an unoptimized MSR is probably fifty cycles, I'd guess.
RDMSR to a non-fastpath MSR is more like a hundred cycles:
[ 104.151166] x86/bench: ---------------------------
[ 104.155350] x86/bench: | Running x86 benchmarks: |
[ 104.159530] x86/bench:
-------------------------------------------------------------------
[ 104.167604] x86/bench: | RDTSC-cycles: hot (±noise) /
cold (±noise)
[ 104.175870] x86/bench:
-------------------------------------------------------------------
Ancient box (10 years old):
x86/bench: rdmsr : 36 /
17 (±29.4%)
x86/bench: wrmsr : 198 /
245
AMD box (2 years old):
...
[ 173.208130] x86/bench: rdmsr : 121 /
169 (±18.9%)
[ 174.633653] x86/bench: wrmsr : 365 /
422 (± 9.2%)
Intel box (1 year old):
...
[ 130.185195] x86/bench: rdmsr : 100 /
112
[ 131.263560] x86/bench: wrmsr : 492 /
728 (±15.3%)
so the RDMSR cost got progressively worse as MSRs got farther and farther away
from the core and microcode execution got progressively worse as well.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
