lkml.org 
[lkml]   [2015]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] context_tracking,x86: remove extraneous irq disable & enable from context tracking on syscall entry
On 05/01/2015 12:34 PM, Ingo Molnar wrote:
>
> * Rik van Riel <riel@redhat.com> wrote:
>
>>> I can understand people running hard-RT workloads not wanting to
>>> see the overhead of a timer tick or a scheduler tick with variable
>>> (and occasionally heavy) work done in IRQ context, but the jitter
>>> caused by a single trivial IPI with constant work should be very,
>>> very low and constant.
>>
>> Not if the realtime workload is running inside a KVM guest.
>
> I don't buy this:
>
>> At that point an IPI, either on the host or in the guest, involves a
>> full VMEXIT & VMENTER cycle.
>
> So a full VMEXIT/VMENTER costs how much, 2000 cycles? That's around 1
> usec on recent hardware, and I bet it will get better with time.
>
> I'm not aware of any hard-RT workload that cannot take 1 usec
> latencies.

Now think about doing this kind of IPI from inside a guest,
to another VCPU on the same guest.

Now you are looking at VMEXIT/VMENTER on the first VCPU,
plus the cost of the IPI on the host, plus the cost of
the emulation layer, plus VMEXIT/VMENTER on the second
VCPU to trigger the IPI work, and possibly a second
VMEXIT/VMENTER for IPI completion.

I suspect it would be better to do RCU callback offload
in some other way.

--
All rights reversed


\
 
 \ /
  Last update: 2015-05-01 20:41    [W:0.149 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site