Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

* Thomas Gleixner wrote: > On Mon, 26 Mar 2018, Eric Dumazet wrote: > > On Sun, Mar 25, 2018 at 11:40 PM Ingo Molnar wrote: > > > If performance matters then the relevant MSR events should be added and > > > gsysd > > > should be updated to support MSR

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

* Thomas Gleixner wrote: > On Mon, 26 Mar 2018, Eric Dumazet wrote: > > On Sun, Mar 25, 2018 at 11:40 PM Ingo Molnar wrote: > > > If performance matters then the relevant MSR events should be added and > > > gsysd > > > should be updated to support MSR events. > > > > > > > Thanks for the

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On Mon, 26 Mar 2018, Eric Dumazet wrote: > On Sun, Mar 25, 2018 at 11:40 PM Ingo Molnar wrote: > > If performance matters then the relevant MSR events should be added and > > gsysd > > should be updated to support MSR events. > > > > Thanks for the hints Ingo. I have forwarded

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On Mon, 26 Mar 2018, Eric Dumazet wrote: > On Sun, Mar 25, 2018 at 11:40 PM Ingo Molnar wrote: > > If performance matters then the relevant MSR events should be added and > > gsysd > > should be updated to support MSR events. > > > > Thanks for the hints Ingo. I have forwarded them. > > I am

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

* Borislav Petkov wrote: > On Sat, Mar 24, 2018 at 07:29:48AM -0700, Eric Dumazet wrote: > > It is named gsysd, "Google System Tool", a daemon+cli that is run > > on all machines in production to provide a generic interface > > for interacting with the system hardware. > > So

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

* Borislav Petkov wrote: > On Sat, Mar 24, 2018 at 07:29:48AM -0700, Eric Dumazet wrote: > > It is named gsysd, "Google System Tool", a daemon+cli that is run > > on all machines in production to provide a generic interface > > for interacting with the system hardware. > > So I'm wondering if

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On 03/25/18 07:12, Borislav Petkov wrote: > > So I'm wondering if poking at the hardware like that is a really optimal > design. Maybe it would be cleaner if the OS would provide properly > abstracted sysfs interfaces instead of raw MSRs. For a couple of > reasons: > It's most definitely not.

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On 03/25/18 07:12, Borislav Petkov wrote: > > So I'm wondering if poking at the hardware like that is a really optimal > design. Maybe it would be cleaner if the OS would provide properly > abstracted sysfs interfaces instead of raw MSRs. For a couple of > reasons: > It's most definitely not.

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On Sat, Mar 24, 2018 at 07:29:48AM -0700, Eric Dumazet wrote: > It is named gsysd, "Google System Tool", a daemon+cli that is run > on all machines in production to provide a generic interface > for interacting with the system hardware. So I'm wondering if poking at the hardware like that is a

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On Sat, Mar 24, 2018 at 07:29:48AM -0700, Eric Dumazet wrote: > It is named gsysd, "Google System Tool", a daemon+cli that is run > on all machines in production to provide a generic interface > for interacting with the system hardware. So I'm wondering if poking at the hardware like that is a

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On 03/24/2018 01:09 AM, Ingo Molnar wrote: > > * Eric Dumazet wrote: > >> I noticed high latencies caused by a daemon periodically reading >> various MSR on all cpus. KASAN kernels would see ~10ms latencies >> simply reading one MSR. Even without KASAN, sending IPI to CPU

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On 03/24/2018 01:09 AM, Ingo Molnar wrote: > > * Eric Dumazet wrote: > >> I noticed high latencies caused by a daemon periodically reading >> various MSR on all cpus. KASAN kernels would see ~10ms latencies >> simply reading one MSR. Even without KASAN, sending IPI to CPU >> in deep sleep

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On Sat, 24 Mar 2018, Ingo Molnar wrote: > * Eric Dumazet wrote: > > > I noticed high latencies caused by a daemon periodically reading > > various MSR on all cpus. KASAN kernels would see ~10ms latencies > > simply reading one MSR. Even without KASAN, sending IPI to CPU > >

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

On Sat, 24 Mar 2018, Ingo Molnar wrote: > * Eric Dumazet wrote: > > > I noticed high latencies caused by a daemon periodically reading > > various MSR on all cpus. KASAN kernels would see ~10ms latencies > > simply reading one MSR. Even without KASAN, sending IPI to CPU > > in deep sleep state

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

* Eric Dumazet wrote: > I noticed high latencies caused by a daemon periodically reading > various MSR on all cpus. KASAN kernels would see ~10ms latencies > simply reading one MSR. Even without KASAN, sending IPI to CPU > in deep sleep state or blocking hard IRQ in a a

Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

* Eric Dumazet wrote: > I noticed high latencies caused by a daemon periodically reading > various MSR on all cpus. KASAN kernels would see ~10ms latencies > simply reading one MSR. Even without KASAN, sending IPI to CPU > in deep sleep state or blocking hard IRQ in a a long section, > then

[PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

I noticed high latencies caused by a daemon periodically reading various MSR on all cpus. KASAN kernels would see ~10ms latencies simply reading one MSR. Even without KASAN, sending IPI to CPU in deep sleep state or blocking hard IRQ in a a long section, then waiting for the answer can consume

[PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule

I noticed high latencies caused by a daemon periodically reading various MSR on all cpus. KASAN kernels would see ~10ms latencies simply reading one MSR. Even without KASAN, sending IPI to CPU in deep sleep state or blocking hard IRQ in a a long section, then waiting for the answer can consume