On Wed, Nov 29, 2017 at 10:13 AM, Konstantin Belousov <kostik...@gmail.com> wrote: > On Wed, Nov 29, 2017 at 04:33:50PM +0100, Hans Petter Selasky wrote: >> Hi Nathan, >> >> The chunk below causes sched_pin() to stop working and should be removed >> from your commit ??!! >> >> It probably explains the hangs seen recently reported by various brave >> people running 12-current :-) >> >> Specifically I see threads migrating between CPUs when td->td_pinned > 0 >> using the LinuxKPI RCU API, which in turn leads to a hang when trying to >> synchronize RCU. >> >> --HPS >> >> diff --git a/sys/kern/sched_ule.c b/sys/kern/sched_ule.c >> index 5c8bae5afa1..bd4b505f6c3 100644 >> --- a/sys/kern/sched_ule.c >> +++ b/sys/kern/sched_ule.c >> @@ -2453,7 +2453,7 @@ sched_add(struct thread *td, int flags) >> * Pick the destination cpu and if it isn't ours transfer to the >> * target cpu. >> */ >> - td_get_sched(td)->ts_cpu = curcpu; /* Pick something valid to >> start */ >> +// td_get_sched(td)->ts_cpu = curcpu; /* Pick something valid to >> start */ >> cpu = sched_pickcpu(td, flags); >> tdq = sched_setcpu(td, cpu, flags); >> tdq_add(tdq, td, flags); > > To clarify. It seems that this change breaks sched_bind(). > > It might be that LinuxKPI does use sched_pin() in somewhat questionable > way. Namely, the code puts the thread off the CPU (e.g. by taking a > lock). Then, is it guaranteed that the pinned thread returns to the same > cpu after sched_add() ? > > I think that the second behaviour is not guaranteed, but it might > happens by the way the things are arranged. If guaranteed, then the > sched_pin() breakage is same as for sched_bind(). >
I see the same breakage on PowerPC with the dtsec(4) driver, which pins interrupts to CPUs, now causing interrupts to migrate to cores without the matching portal mapping. - Justin _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"