<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 29, 2017 at 10:56 AM, Björn Brandenburg <span dir="ltr"><<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 29. Aug 2017, at 16:45, Meng Xu <<a href="mailto:xumengpanda@gmail.com">xumengpanda@gmail.com</a>> wrote:<br>
><br>
> On Tue, Aug 29, 2017 at 10:26 AM, Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org">bbb@mpi-sws.org</a>> wrote:<br>
><br>
> > On 29. Aug 2017, at 16:23, Meng Xu <<a href="mailto:xumengpanda@gmail.com">xumengpanda@gmail.com</a>> wrote:<br>
> ><br>
> >>> 3) It’s not just rtspin that will be confused — likely all of LITMUS^RT’s<br>
> >>> budget tracking and enforcement code will not work as expected under<br>
> >>> virtualization (when given vCPUs with non-100% utilization). This is because<br>
> >>> the scheduler is not aware of any times during which a vCPU does not receive<br>
> >>> service, so tasks will be charged for bogus execution time.<br>
> >><br>
> >> This sounds really bad.<br>
> ><br>
> > I'm wondering if it's designed for this on purpose by Linux people?<br>
> > If yes, they must have discussed some tradeoffs; otherwise, it could<br>
> > lead to some issues.<br>
><br>
> What is the alternative? The guest kernel does not know when the vCPU is actually making progress. So how could it react in any other way? Or is there some interface exported by Xen that would allow us to infer exactly how much service a vCPU received?<br>
><br>
> When a VCPU is preempted, it notify the guest kernel; when a VCPU resumes, it notify the guest kernel. Then the guest kernel knows how long the vcpu is preempted.<br>
> I'm unaware this interface has been implemented in Xen or not. But I think it's doable.<br>
<br>
</span>I agree that it’s definitely doable in a para-virtualization setting with a cooperative guest kernel, and I’d bet something similar has been done in the context of the lock-holder preemption problem.<br>
<br>
It’s less obvious to me how one would solve this under full/native virtualization, where the guest OS is blissfully unaware of the fact that it is being virtualized without 100% CPU capacity.<br>
<span class=""><br>
> (I'm thinking in research perspective. If this issue is serious enough, I guess it could be a research problem to look at)<br>
<br>
</span>Let me know if you end up working on this and need a collaborator. ;-)<br></blockquote><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">Sure! I need to do some survey about this first. :)</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">Best,</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small">Meng</div><br></div><div><div class="gmail_default" style="font-size:small;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- Björn<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-----------<br>Meng Xu<br>PhD Candidate in Computer and Information Science<br>University of Pennsylvania<br><a href="http://www.cis.upenn.edu/~mengxu/" target="_blank">http://www.cis.upenn.edu/~mengxu/</a></div></div></div>
</div></div>