Messages in this thread | | | Subject | Re: Crash in fair scheduler | From | Dietmar Eggemann <> | Date | Tue, 3 Dec 2019 16:08:35 +0100 |
| |
On 03/12/2019 12:09, Valentin Schneider wrote: > On 03/12/2019 10:40, Dietmar Eggemann wrote: >> On 03/12/2019 11:30, Valentin Schneider wrote: >>> On 03/12/2019 09:11, Schmid, Carsten wrote: >> >> [...] >> >>> That looks a lot like a recent issue we've had, see >>> >>> https://lore.kernel.org/lkml/20191108131909.428842459@infradead.org/ >>> >>> The issue is caused by >>> >>> 67692435c411 ("sched: Rework pick_next_task() slow-path") >>> >>> which 5.4-rc2 has (without the fix which landed in -rc7) but 4.14 really >>> shouldn't, unless the kernel you're using has had core scheduling somehow >>> backported to it? >>> >>> I've only scraped the surface but I'd like to first ask: can you reproduce >>> the issue on v5.4 final ? >> >> Can't be. 4.14.86 does not have ("sched: Rework pick_next_task() >> slow-path"). >> > > Right, which is why I wondered if the kernel under test had had that > backported to it for some reason (e.g. core scheduling). Peter pointed out > that this is a slightly different issue (nr_running matches the rbt), so > this is probably unrelated.
I can't reproduce it on Arm64 Juno running 4.14.86. I suppose that there is no extra reproducer testcase since the issue happened with prev->sched_class eq. &idle_sched_class [prev eq. swapper/X 0] in the simple path of pick_next_task_fair().
I'm running with CONFIG_SCHED_AUTOGROUP=y and CONFIG_FAIR_GROUP_SCHED=y some taskgroup related tests for hours now. So the sched_entity (se) can be a task, an autogroup or a taskgroup in the simple path. pref is either swapper/X or migration/X.
| |