[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.1811220838410.21108@cbobk.fhfr.pm>
Date: Thu, 22 Nov 2018 08:42:33 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Andi Kleen <ak@...ux.intel.com>
cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Tom Lendacky <thomas.lendacky@....com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
David Woodhouse <dwmw@...zon.co.uk>,
Dave Hansen <dave.hansen@...el.com>,
Casey Schaufler <casey.schaufler@...el.com>,
Asit Mallick <asit.k.mallick@...el.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Jon Masters <jcm@...hat.com>,
Waiman Long <longman9394@...il.com>,
Greg KH <gregkh@...uxfoundation.org>,
Dave Stewart <david.c.stewart@...el.com>,
Kees Cook <keescook@...omium.org>
Subject: Re: [patch 17/24] x86/speculation: Move IBPB control out of
switch_mm()
On Wed, 21 Nov 2018, Andi Kleen wrote:
> > + * This could be optimized by keeping track of the last
> > + * user task per cpu and avoiding the barrier when the task
> > + * is immediately scheduled back and the thread inbetween
> > + * was a kernel thread. It's dubious whether that'd be
> > + * worth the extra load/store and conditional operations.
> > + * Keep it optimized for the common case where the TIF bit
> > + * is not set.
> > + */
>
> The optimization was there before and you removed it?
>
> It's quite important for switching to idle and back. With your variant short IOs
> that do short idle waits will be badly impacted.
The question is what scenario to optimize for.
Either you penalize everybody in the default prctl+seccomp setup
(irrespective of it's TIF flag value), as you have the extra overhead on
each and every switch_to() (to check exactly for this back-to-back
scheduling), or you penalize only those tasks that are penalized anyway by
the IBPB flush.
I think the latter (which is what this patch implements) makes more sense.
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists