[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k0b1jvpn.ffs@tglx>
Date: Wed, 04 May 2022 15:03:48 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Marcelo Tosatti <mtosatti@...hat.com>
Cc: linux-kernel@...r.kernel.org, Nitesh Lal <nilal@...hat.com>,
Nicolas Saenz Julienne <nsaenzju@...hat.com>,
Frederic Weisbecker <frederic@...nel.org>,
Christoph Lameter <cl@...ux.com>,
Juri Lelli <juri.lelli@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Alex Belits <abelits@...its.com>, Peter Xu <peterx@...hat.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Oscar Shiang <oscar0225@...email.tw>
Subject: Re: [patch v12 13/13] task isolation: only TIF_TASK_ISOL if task
isolation is enabled
On Tue, May 03 2022 at 16:12, Marcelo Tosatti wrote:
> On Wed, Apr 27, 2022 at 09:45:54AM +0200, Thomas Gleixner wrote:
> It seems to be inline with the remaining TIF_ bits:
>
> if (ti_work & _TIF_NOTIFY_RESUME)
> tracehook_notify_resume(regs);
>
> + if (ti_work & _TIF_TASK_ISOL)
> + task_isol_exit_to_user_mode();
> +
>
>
> And there is even:
I know that the bit is defined, but that does still not make an argument.
> By looking at the code, we see the sites where this bit is set are:
Again. I'm able to read the patches myself.
> Would you prefer an explanation, in words, when these bits are set, when
> they are cleared?
No. The point is that contrary to TIF_NOTIFY_RESUME and other TIF bits,
this is going to end up being sprinkled all over the place.
With the current vmstat quiesce that's limited, but it's bound to
increase and spread simply because the whole thing has no semantics and
it's all headed to be adhoc cure for the isolation itch of the day.
Thanks,
tglx
Powered by blists - more mailing lists