Messages in this thread | | | Subject | Re: [patch 1/4] add basic task isolation prctl interface | From | nsaenzju@redhat ... | Date | Wed, 28 Jul 2021 19:08:45 +0200 |
| |
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
| |