-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/07/2015 03:06 PM, Paul E. McKenney wrote: > On Sat, Feb 07, 2015 at 09:30:41AM +0100, Frederic Weisbecker > wrote: >> On Fri, Feb 06, 2015 at 11:14:53PM -0800, Paul E. McKenney >> wrote: >>> On Fri, Feb 06, 2015 at 10:34:21PM -0800, Paul E. McKenney >>> wrote: >>>> On Fri, Feb 06, 2015 at 10:53:34PM -0500, Rik van Riel >>>> wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> >>>>> On 02/06/2015 06:15 PM, Frederic Weisbecker wrote: >>>>> >>>>>> Just a few things then: >>>>>> >>>>>> 1) In this case rename context_tracking_user_enter/exit() >>>>>> to context_tracking_enter() and context_tracking_exit(), >>>>>> since it's not anymore about user only but about any >>>>>> generic context. >>>>>> >>>>>> 2) We have the "WARN_ON_ONCE(!current->mm);" condition >>>>>> that is a debug check specific to userspace transitions >>>>>> because kernel threads aren't expected to resume to >>>>>> userspace. Can we also expect that we never switch >>>>>> to/from guest from a kernel thread? AFAICS this happens >>>>>> from an ioctl (thus user task) in x86 for kvm. But I only >>>>>> know this case. >>>>>> >>>>>> 3) You might want to update a few comments that assume we >>>>>> only deal with userspace transitions. >>>>>> >>>>>> 4) trace_user_enter/exit() should stay user-transitions >>>>>> specific. >>>>> >>>>> Paul, would you like me to send follow-up patches with the >>>>> cleanups suggested by Frederic, or would you prefer me to >>>>> send a new series with the cleanups integrated? >>>> >>>> I would prefer a new series, in order to prevent possible >>>> future confusion. >>> >>> Of course, if Frederic would rather push them himself, I am >>> fine with that. And in that case, you should ask him for his >>> preferences, which just might differ from mine. ;-) >> >> I prefer a new series too. Now whether you or me take the >> patches, I don't mind either way :-) >> >> Also I wonder how this feature is going to be enabled. Will it be >> enabled on full dynticks or should it be a seperate feature >> depending on full dynticks? Or even just CONFIG_RCU_USER_EQS? >> Because I'm still unclear about how and what this is used, if it >> involves full dynticks or only RCU extended quiescent states. > > Well, we certainly need it documented. And validation > considerations would push for keeping the number of possible > combinations low, while paranoia about added feature would push for > having it be separately enabled. And if distros are going to > enable this at build time, we either need -serious- validation or a > way to disable at boot time. > > On the desired/required combinations of features, let's see... > > If I understand this completely, which I probably don't, we have > the following considerations: > > o NO_HZ_FULL: Needed to get rid of the scheduling-clock interrupt > during guest execution, though I am not sure whether we really have > that completely wired up with this patch set. Regardless, Rik, for > your use case, do you care about whether or not the guest gets > interrupted by the host's scheduling-clock interrupts? (Based on > discussion in this thread, my guess is "yes".) > > o RCU_NOCB_CPUS: Implied by NO_HZ_FULL, but only on CPUs actually > enabled for NO_HZ_FULL operation, either by NO_HZ_FULL_ALL at build > time or by nohz_full= at boot time. Needed to avoid interrupting > the guest with host RCU callback invocation. Rik, does your use > case care about guests being interrupted by RCU callback > invocation? (Based on discussion in this thread, my guess is > "yes".) > > o RCU_USER_EQS: Implied by NO_HZ_FULL, and I would have to go look > to see what relation this has to nohz_full=. Needed for RCU to be > able to recognize userspace-execution quiescent states on a given > CPU without disturbing that CPU. Unless I am missing something > subtle, you have to have this for this patch series to make sense. > > If my guesses are correct, the best approach would be to have this > new mode of operation implied by NO_HZ_FULL. I agree. It makes sense to have all three, and all three are enabled in the configuration we use. I cannot think of a case where someone would significantly benefit from just one or two of the above, except maybe for debugging reasons. Having NO_HZ_FULL enable all the above, either through a boot time commandline option, or just by default, would make sense. - -- All rights reversed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU2NVpAAoJEM553pKExN6DxxUH/RwpZI6dRYvIQbtY2y93ax5/ Lba4QbmZ6n6AnGXrtlpwEQMSMvLawKqT9ZFSwzKeSarX6Uu4aRCdi8td34ruu9rg hfhv8hD1z15deYc0UPKUCbZrYrIi9uaG/FpioafDmPH+P4T2bFdvn7d/bKIoiaBM T1QA+LNddRxOhtayrIEDH1BnPKgXw9V8f7/mGQPmRf+oRz+Hgn6DPpEm0kTbqn+L RkhHNPemJ8bMaIwntAwzEklgnhkON9zOBe/XFof0lC+SdhtlAVkXPvX+cXiZMQZt 1rEqxK1+S9beeKVX65mLtxZg2omz46qz7SQRUGf3If2wHZXQtIRnvtlyCsDu/AI= =gj2E -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
