| Message ID | 8d887e59ca713726f4fcb25a316e1e932b02823e.camel@marvell.com |
|---|---|
| Headers | show |
| Series | "Task_isolation" mode | expand |
Alex, On Mon, Nov 23 2020 at 17:56, Alex Belits wrote: > .../admin-guide/kernel-parameters.txt | 6 + > drivers/base/cpu.c | 23 + > include/linux/hrtimer.h | 4 + > include/linux/isolation.h | 326 ++++++++ > include/linux/sched.h | 5 + > include/linux/tick.h | 3 + > include/uapi/linux/prctl.h | 6 + > init/Kconfig | 27 + > kernel/Makefile | 2 + > kernel/isolation.c | 714 ++++++++++++++++++ > kernel/signal.c | 2 + > kernel/sys.c | 6 + > kernel/time/hrtimer.c | 27 + > kernel/time/tick-sched.c | 18 + I asked you before to split this up into bits and pieces and argue and justify each change. Throwing this wholesale over the fence is going nowhere. It's not revieable at all. Aside of that ignoring review comments is a sure path to make yourself ignored: > +/* > + * Logging > + */ > +int task_isolation_message(int cpu, int level, bool supp, const char *fmt, ...); > + > +#define pr_task_isol_emerg(cpu, fmt, ...) \ > + task_isolation_message(cpu, LOGLEVEL_EMERG, false, fmt, ##__VA_ARGS__) The comments various people made about that are not going away and none of this is going near anything I'm responsible for unless you provide these independent of the rest and with a reasonable justification why you can't use any other existing mechanism or extend it for your use case. Thanks, tglx
On 11/23/20 9:42 AM, Alex Belits wrote: > This is an update of task isolation work that was originally done by > Chris Metcalf <cmetcalf@mellanox.com> and maintained by him until > November 2017. It is adapted to the current kernel and cleaned up to > implement its functionality in a more complete and cleaner manner. I am having problems applying the patchset to today's linux-next. Which kernel should I be using ? Thanks, Tom
On Tue, 2020-11-24 at 08:36 -0800, Tom Rix wrote: > External Email > > ------------------------------------------------------------------- > --- > > On 11/23/20 9:42 AM, Alex Belits wrote: > > This is an update of task isolation work that was originally done > > by > > Chris Metcalf <cmetcalf@mellanox.com> and maintained by him until > > November 2017. It is adapted to the current kernel and cleaned up > > to > > implement its functionality in a more complete and cleaner manner. > > I am having problems applying the patchset to today's linux-next. > > Which kernel should I be using ? The patches are against Linus' tree, in particular, commit a349e4c659609fd20e4beea89e5c4a4038e33a95 -- Alex
On Tue, Nov 24, 2020 at 05:40:49PM +0000, Alex Belits wrote: > > On Tue, 2020-11-24 at 08:36 -0800, Tom Rix wrote: > > External Email > > > > ------------------------------------------------------------------- > > --- > > > > On 11/23/20 9:42 AM, Alex Belits wrote: > > > This is an update of task isolation work that was originally done > > > by > > > Chris Metcalf <cmetcalf@mellanox.com> and maintained by him until > > > November 2017. It is adapted to the current kernel and cleaned up > > > to > > > implement its functionality in a more complete and cleaner manner. > > > > I am having problems applying the patchset to today's linux-next. > > > > Which kernel should I be using ? > > The patches are against Linus' tree, in particular, commit > a349e4c659609fd20e4beea89e5c4a4038e33a95 Is there any reason to base on that commit in particular? Generally it's preferred that a series is based on a tag (so either a release or an -rc kernel), and that the cover letter explains what the base is. If you can do that in future it'll make the series much easier to work with. Thanks, Mark.
On Wed, 2020-12-02 at 14:02 +0000, Mark Rutland wrote: > On Tue, Nov 24, 2020 at 05:40:49PM +0000, Alex Belits wrote: > > > > > I am having problems applying the patchset to today's linux-next. > > > > > > Which kernel should I be using ? > > > > The patches are against Linus' tree, in particular, commit > > a349e4c659609fd20e4beea89e5c4a4038e33a95 > > Is there any reason to base on that commit in particular? No specific reason for that particular commit. > Generally it's preferred that a series is based on a tag (so either a > release or an -rc kernel), and that the cover letter explains what > the > base is. If you can do that in future it'll make the series much > easier > to work with. Ok. -- Alex
Hi! > General description > > This is the result of development and maintenance of task isolation > functionality that originally started based on task isolation patch > v15 and was later updated to include v16. It provided predictable > environment for userspace tasks running on arm64 processors alongside > with full-featured Linux environment. It is intended to provide > reliable interruption-free environment from the point when a userspace > task enters isolation and until the moment it leaves isolation or > receives a signal intentionally sent to it, and was successfully used > for this purpose. While CPU isolation with nohz provides an > environment that is close to this requirement, the remaining IPIs and > other disturbances keep it from being usable for tasks that require > complete predictability of CPU timing. So... what kind of guarantees does this aim to provide / what tasks it is useful for? For real time response, we have other approaches. If you want to guarantee performnace of the "isolated" task... I don't see how that works. Other tasks on the system still compete for DRAM bandwidth, caches, etc... So... what is the usecase? Pavel -- http://www.livejournal.com/~pavelmachek
Pavel, On Sat, Dec 05 2020 at 21:40, Pavel Machek wrote: > So... what kind of guarantees does this aim to provide / what tasks it > is useful for? > > For real time response, we have other approaches. Depends on your requirements. Some problems are actually better solved with busy polling. See below. > If you want to guarantee performnace of the "isolated" task... I don't > see how that works. Other tasks on the system still compete for DRAM > bandwidth, caches, etc... Applications which want to run as undisturbed as possible. There is quite a range of those: - Hardware in the loop simulation is today often done with that crude approach of "offlining" a CPU and then instead of playing dead jumping to a preloaded bare metal executable. That's a horrible hack and impossible to debug, but gives them the results they need to achieve. These applications are well optimized vs. cache and memory foot print, so they don't worry about these things too much and they surely don't run on SMI and BIOS value add inflicted machines. Don't even think about waiting for an interrupt to achieve what these folks are doing. So no, there are problems which a general purpose realtime OS cannot solve ever. - HPC computations on large data sets. While the memory foot print is large the access patterns are cache optimized. The problem there is that any unnecessary IPI, tick interrupt or whatever nuisance is disturbing the carefully optimized cache usage and alone getting rid of the timer interrupt gained them measurable performance. Even very low single digit percentage of runtime saving is valuable for these folks because the compute time on such beasts is expensive. - Realtime guests in KVM. With posted interrupts and a fully populated host side page table there is no point in running host side interrupts or IPIs for random accounting or whatever purposes as they affect the latency in the guest. With all the side effects mitigated and a properly set up guest and host it is possible to get to a zero exit situation after the bootup phase which means pretty much matching bare metal behaviour. Yes, you can do that with e.g. Jailhouse as well, but you lose lots of the fancy things KVM provides. And people care about these not just because they are fancy. They care because their application scenario needs them. There are more reasons why people want to be able to get as much isolation from the OS as possible but at the same time have a sane execution environment, debugging, performance monitoring and the OS provided protection mechanisms instead of horrible hacks. Isolation makes sense for a range of applications and there is no reason why Linux should not support them. Thanks, tglx
On Sun, Dec 06, 2020 at 12:25:45AM +0100, Thomas Gleixner wrote: > Pavel, > > On Sat, Dec 05 2020 at 21:40, Pavel Machek wrote: > > So... what kind of guarantees does this aim to provide / what tasks it > > is useful for? > > > > For real time response, we have other approaches. > > Depends on your requirements. Some problems are actually better solved > with busy polling. See below. > > > If you want to guarantee performnace of the "isolated" task... I don't > > see how that works. Other tasks on the system still compete for DRAM > > bandwidth, caches, etc... > > Applications which want to run as undisturbed as possible. There is > quite a range of those: > > - Hardware in the loop simulation is today often done with that crude > approach of "offlining" a CPU and then instead of playing dead > jumping to a preloaded bare metal executable. That's a horrible hack > and impossible to debug, but gives them the results they need to > achieve. These applications are well optimized vs. cache and memory > foot print, so they don't worry about these things too much and they > surely don't run on SMI and BIOS value add inflicted machines. > > Don't even think about waiting for an interrupt to achieve what > these folks are doing. So no, there are problems which a general > purpose realtime OS cannot solve ever. > > - HPC computations on large data sets. While the memory foot print is > large the access patterns are cache optimized. > > The problem there is that any unnecessary IPI, tick interrupt or > whatever nuisance is disturbing the carefully optimized cache usage > and alone getting rid of the timer interrupt gained them measurable > performance. Even very low single digit percentage of runtime saving > is valuable for these folks because the compute time on such beasts > is expensive. > > - Realtime guests in KVM. With posted interrupts and a fully populated > host side page table there is no point in running host side > interrupts or IPIs for random accounting or whatever purposes as > they affect the latency in the guest. With all the side effects > mitigated and a properly set up guest and host it is possible to get > to a zero exit situation after the bootup phase which means pretty > much matching bare metal behaviour. > > Yes, you can do that with e.g. Jailhouse as well, but you lose lots > of the fancy things KVM provides. And people care about these not > just because they are fancy. They care because their application > scenario needs them. > > There are more reasons why people want to be able to get as much > isolation from the OS as possible but at the same time have a sane > execution environment, debugging, performance monitoring and the OS > provided protection mechanisms instead of horrible hacks. > > Isolation makes sense for a range of applications and there is no reason > why Linux should not support them. One good client for the task isolation is Open Data Plane. There are even some code stubs supposed to enable isolation where needed. > > If you want to guarantee performnace of the "isolated" task... I don't > > see how that works. Other tasks on the system still compete for DRAM > > bandwidth, caches, etc... My experiments say that typical delay caused by dry IPI or syscall is 2000-20000 'ticks'. Typical delay caused by cache miss is 3-30 ticks. To guarantee cache / memory bandwidth, one can use resctrl. Linux has implementation of it for x86 only, but arm64 has support for for resctrl on CPU side. Thanks, Yury > Thanks, > > tglx