Messages in this thread | | | Date | Wed, 29 Sep 2021 13:54:17 +0200 | From | Peter Zijlstra <> | Subject | Re: [patch 4/5] sched: Delay task stack freeing on RT |
| |
On Tue, Sep 28, 2021 at 02:24:30PM +0200, Thomas Gleixner wrote:
> --- a/kernel/exit.c > +++ b/kernel/exit.c > @@ -172,6 +172,11 @@ static void delayed_put_task_struct(stru > kprobe_flush_task(tsk); > perf_event_delayed_put(tsk); > trace_sched_process_free(tsk); > + > + /* RT enabled kernels delay freeing the VMAP'ed task stack */ > + if (IS_ENABLED(CONFIG_PREEMPT_RT)) > + put_task_stack(tsk); > + > put_task_struct(tsk); > }
> --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -4846,8 +4846,12 @@ static struct rq *finish_task_switch(str > if (prev->sched_class->task_dead) > prev->sched_class->task_dead(prev); > > - /* Task is done with its stack. */ > - put_task_stack(prev); > + /* > + * Release VMAP'ed task stack immediate for reuse. On RT > + * enabled kernels this is delayed for latency reasons. > + */ > + if (!IS_ENABLED(CONFIG_PREEMPT_RT)) > + put_task_stack(prev); > > put_task_struct_rcu_user(prev); > }
Having this logic split across two files seems unfortunate and prone to 'accidents'. Is there a real down-side to unconditionally doing it in delayed_put_task_struct() ?
/me goes out for lunch... meanwhile tglx points at: 68f24b08ee89.
Bah.. Andy?
| |