[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] null scheduler bug
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/ Attachment:
rcu-quiesc-patch.patch Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |