Re: [Xen-devel] null scheduler bug

[Milan Boberic <milanboberic94@xxxxxxxxx>]

Hi,
I applied patch and vwfi=native and everything works fine, I can
create and destroy guest domain as many times as I want.

I have to ask, will this patch have any impact on performance (I will
test it later, but I just need your opinions)?
And what this patch exactly do? I need to fully understand it because
I need to document it in my master thesis which will be finished soon
thanks to you people :D

Thank you for taking your time to make this patch, best regards!
On Thu, Sep 27, 2018 at 11:51 AM Dario Faggioli <dfaggioli@xxxxxxxx> wrote:
>
> On Tue, 2018-09-25 at 19:49 +0200, Dario Faggioli wrote:
> > [Adding a few people to the Cc-list. See below...]
> > On Tue, 2018-09-25 at 12:15 +0100, Julien Grall wrote:
> > > On 09/25/2018 10:02 AM, Dario Faggioli wrote:
> > > > On Mon, 2018-09-24 at 22:46 +0100, Julien Grall wrote:
> > > > >
> > My knowledge of RCU themselves would need refreshing, though. I
> > managed
> > to getbecome reasonably familiar with how the implementation we
> > imported works back then, when working on the said issue, but I guess
> > I
> > better go check the code again.
> >
> > I'm Cc-ing the people that have reviewed the patches and helping with
> > the idle timer problem, in case anyone has bright ideas out of the
> > top
> > of his head.
> >
> > Perhaps we should "just" get away from using RCU for domain
> > destruction
> > (but I'm just tossing the idea around, without much consideration
> > about
> > whether it's the right solution, or about how hard/feasible it really
> > is).
> >
> > Or maybe we can still use the timer, in some special way, if we have
> > wfi=native (or equivalent)...
> >
> So, I've had a look (but only a quick one).
>
> If we want to do something specific within the domain destruction path,
> we can add an rcu_barrier() there (I mean in domain_destroy()).
> However, that does not feel right either. Also, how can we be sure that
> the CPU never going through idle (as far as Xen knows, at least), isn't
> going to be problem for other RCU calls as well?
>
> Another thing that we can do is to act on the parameters that control
> the threshold which decides when a quiescent state is forced. This was
> basically what Julien was suggesting, but I still would avoid to do
> that always.
>
> So, basically, in this hackish patch attached, I added a new boot
> command line argument, called rcu_force_quiesc. If set to true,
> thresholds are set so that quiescence is always forced at each
> invocation of call_rcu(). And even if the new param is not explicitly
> specified, I do tweak the threshold when "wfi=native" is.
>
> Milan, can you apply this patch, add "wfi=native" again, and re-test?
> If it works, we'll decide what to do next.
>
> E.g., we can expose the RCU threshold via the appropriate set of boot
> time parameters --like Linux, from where this code comes, did/does--
> and document how they should be set, if one wants to use "wfi=native".
>
> Thanks and Regards,
> Dario
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Software Engineer @ SUSE https://www.suse.com/

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel