LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: nsaenzju@redhat.com To: Marcelo Tosatti <mtosatti@redhat.com> Cc: Frederic Weisbecker <frederic@kernel.org>, linux-kernel@vger.kernel.org, Nitesh Lal <nilal@redhat.com>, Christoph Lameter <cl@linux.com>, Juri Lelli <juri.lelli@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Alex Belits <abelits@marvell.com>, Peter Xu <peterx@redhat.com>, Thomas Gleixner <tglx@linutronix.de> Subject: Re: [patch 1/4] add basic task isolation prctl interface Date: Wed, 28 Jul 2021 19:08:45 +0200 [thread overview] Message-ID: <441d94dbd93443839d31fdfe5f6048de35b0d7b0.camel@redhat.com> (raw) In-Reply-To: <20210728131610.GA11900@fuller.cnet> On Wed, 2021-07-28 at 10:16 -0300, Marcelo Tosatti wrote: > > For example, let's say we introduce ISOL_F_QUIESCE_DEFER_TLB_FLUSH, this will > > defer relatively short IPIs on isolated CPUs in exchange for a longer flush > > whenever we enter the kernel (syscall, IRQs, NMI, etc...). > > Why the flush has to be longer when you enter the kernel? What I had in mind was cost of rapid partial flushes (IPIs) vs full flushes on entry, although I haven't really measured anything so the extra latency cost might as well be zero. > ISOL_F_QUIESCE_DEFER_TLB_FLUSH might collapse multiple IPIs > into a single IPI, so the behaviour might be beneficial > for "standard" types of application as well. > > > A latency sensitive > > application might be OK with the former but not with the latter. > > Two alternatives: > > 1) The pattern above, where particular subsystems that might interrupt > the kernel are enabled automatically if the kernel supports it. > > Pros: > Applications which implement this only need to be changed once, > and can benefit from new kernel features. > > Applications can disable particular features if they turn > out to be problematic. > > Cons: > New features might break applications. > > 2) Force applications to enable each new feature individually. > > Pros: Won't cause regressions, kernel behaviour is explicitly > controlled by userspace. > > Cons: Apps won't benefit from new features automatically. > > --- > > It seems to me 1) is preferred. Can also add a sysfs control to > have a "default_isolation_feature" flag, which can be changed > by a sysadmin in case a new feature is undesired. > > Thoughts? I'd still take option 2. Nitesh has a very good point, latency requirements are hit or miss. What's the benefit of enabling new features on an already valid application vs the potential regression? That said I see value in providing means for users that want all features/modes, but it should be an through an explicit action on their part. -- Nicolás Sáenz
next prev parent reply other threads:[~2021-07-28 17:09 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-27 10:38 [patch 0/4] prctl task isolation interface and vmstat sync Marcelo Tosatti 2021-07-27 10:38 ` [patch 1/4] add basic task isolation prctl interface Marcelo Tosatti 2021-07-27 10:48 ` nsaenzju 2021-07-27 11:00 ` Marcelo Tosatti 2021-07-27 12:38 ` nsaenzju 2021-07-27 13:06 ` Marcelo Tosatti 2021-07-27 13:08 ` Marcelo Tosatti 2021-07-27 13:09 ` Frederic Weisbecker 2021-07-27 14:52 ` Marcelo Tosatti 2021-07-27 23:45 ` Frederic Weisbecker 2021-07-28 9:37 ` Marcelo Tosatti 2021-07-28 11:45 ` Frederic Weisbecker 2021-07-28 13:21 ` Marcelo Tosatti 2021-07-28 21:22 ` Frederic Weisbecker 2021-07-28 11:55 ` nsaenzju 2021-07-28 13:16 ` Marcelo Tosatti [not found] ` <CAFki+LkQwoqVTKmgnwLQQM8ua-ixbLp8i+jUT6xF15k6X=89mw@mail.gmail.com> 2021-07-28 16:21 ` Marcelo Tosatti 2021-07-28 17:08 ` nsaenzju [this message] [not found] ` <CAFki+LmHeXmSFze8YEHFNbYA5hLEtnZyk37Yjf-eyOuKa8Os4w@mail.gmail.com> 2021-07-28 16:17 ` Marcelo Tosatti 2021-07-27 10:38 ` [patch 2/4] task isolation: sync vmstats on return to userspace Marcelo Tosatti 2021-07-27 10:38 ` [patch 3/4] mm: vmstat: move need_update Marcelo Tosatti 2021-07-27 10:38 ` [patch 4/4] mm: vmstat_refresh: avoid queueing work item if cpu stats are clean Marcelo Tosatti 2021-07-30 20:18 [patch 0/4] extensible prctl task isolation interface and vmstat sync (v2) Marcelo Tosatti 2021-07-30 20:18 ` [patch 1/4] add basic task isolation prctl interface Marcelo Tosatti [not found] ` <CAFki+Lnf0cs62Se0aPubzYxP9wh7xjMXn7RXEPvrmtBdYBrsow@mail.gmail.com> 2021-07-31 0:49 ` Marcelo Tosatti 2021-07-31 7:47 ` kernel test robot [not found] ` <CAFki+LkQVQOe+5aNEKWDvLdnjWjxzKWOiqOvBZzeuPWX+G=XgA@mail.gmail.com> 2021-08-02 14:16 ` Marcelo Tosatti
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=441d94dbd93443839d31fdfe5f6048de35b0d7b0.camel@redhat.com \ --to=nsaenzju@redhat.com \ --cc=abelits@marvell.com \ --cc=cl@linux.com \ --cc=frederic@kernel.org \ --cc=juri.lelli@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mtosatti@redhat.com \ --cc=nilal@redhat.com \ --cc=peterx@redhat.com \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).