[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <215dc5af-5e81-fb64-9f00-b1e9e8d08297@kernel.org>
Date: Mon, 21 Feb 2022 10:36:01 -0800
From: Andy Lutomirski <luto@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org
Cc: Ben Segall <bsegall@...gle.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH v2 0/8] kernel/fork: Move thread stack free otu of the
scheduler path.
On 2/17/22 02:23, Sebastian Andrzej Siewior wrote:
> This is a follup-up on the patch
> sched: Delay task stack freeing on RT
> https://lkml.kernel.org/r/20210928122411.593486363@linutronix.de
>
> It addresses the review feedback:
> - Decouple stack accounting from its free invocation. The accounting
> happens in do_exit(), the final free call happens later.
>
> - Add put_task_stack_sched() to finish_task_switch(). Here the VMAP
> stack is cached only. If it fails, or in the !VMAP case then the final
> free happens in delayed_put_task_struct(). This is also an oportunity
> to cache the stack.
My first two tries to apply this series to something failed. What's it
based on?
The rest of my review will be based on diffs, not real code, since I
failed to apply it.
Powered by blists - more mailing lists