linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Alex Belits <abelits@marvell.com>,
	 "tglx@linutronix.de" <tglx@linutronix.de>,
	 "pauld@redhat.com" <pauld@redhat.com>,
	 "linux-mm@kvack.org" <linux-mm@kvack.org>,
	 "frederic@kernel.org" <frederic@kernel.org>,
	 "willy@infradead.org" <willy@infradead.org>,
	 "peterz@infradead.org" <peterz@infradead.org>,
	 "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	 Juri Lelli <juri.lelli@redhat.com>,
	 Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: [RFC] tentative prctl task isolation interface
Date: Fri, 15 Jan 2021 13:24:10 +0000 (UTC)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2101151311440.48145@www.lameter.com> (raw)
In-Reply-To: <20210114193430.GA149907@fuller.cnet>

On Thu, 14 Jan 2021, Marcelo Tosatti wrote:

> > How does one do a oneshot flush of OS activities?
>
>         ret = prctl(PR_TASK_ISOLATION_REQUEST, ISOL_F_QUIESCE, 0, 0, 0);
>         if (ret == -1) {
>                 perror("prctl PR_TASK_ISOLATION_REQUEST");
>                 exit(0);
>         }
>
> >
> > I.e. I have a polling loop over numerous shared and I/o devices in user
> > space and I want to make sure that the system is quite before I enter the
> > loop.
>
> You could configure things in two ways: with syscalls allowed or not.

Well syscalls that do not cause deferred processing like getting the time
or determining the current cpu should be ok to use.

And I already said that I want the system to quiet down and allow system
calls. Some indication that deferred actions have occurred may be useful
by f.e. resetting the flag.

> 1) Add a new isolation feature ISOL_F_BLOCK_SYSCALLS (to block certain
> syscalls) along with ISOL_F_SETUP_NOTIF (to notify upon isolation
> breaking):

Well come up with a use case for that .... I know mine. What you propose
could be  useful for debugging for me but I would prefer the quiet down
approach where I determine when I use some syscalls or not and will deal
with the consequences.

>
> > Features that I think may be needed:
> >
> > F_ISOL_QUIESCE		-> quiet down now but allow all OS activities. OS
> > 			activites reset flag
> >
> > F_ISOL_BAREMETAL_HARD	-> No OS interruptions. Fault on syscalls that
> > 			require such actions in the future.
>
> Question: why BAREMETAL ?

To disinguish it from "Realtime". We want the processor for ourselves
without anything else running on it.

> Two comments:
>
> 1) HARD mode could also block activities from different CPUs that can
> interrupt this isolated CPU (for example CPU hotplug, or increasing
> per-CPU trace buffer size).

Blocking? The app should fail if any deferred actions are triggered as a
result of syscalls. It would give a warning with _WARN

> 2) For a type of application it is the case that certain interruptions
> can be tolerated, as long as they do not cross certain thresholds.
> For example, one loses the flexibility to read/write MSRs
> on the isolated CPUs (including performance counters,
> RDT/MBM type MSRs, frequency/power statistics) by
> forcing a "no interruptions" mode.

Does reading these really cause deferred actions by the OS? AFAICT you
could map these into memory as well as read them without OS activities.

"Interruptions that can be tolerated".... Well that is the wild west of
"realtime" where you can define how much of a time slice is "real" and how
much can be use by other processes. I do not think that any of that should
come into this API.



  reply	other threads:[~2021-01-15 13:24 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17 16:28 [PATCH] mm: introduce sysctl file to flush per-cpu vmstat statistics Marcelo Tosatti
2020-11-17 18:03 ` Matthew Wilcox
2020-11-17 19:06   ` Christopher Lameter
2020-11-17 19:09     ` Matthew Wilcox
2020-11-20 18:04       ` Christopher Lameter
2020-11-17 20:23     ` Marcelo Tosatti
2020-11-20 18:02       ` Marcelo Tosatti
2020-11-20 18:20       ` Christopher Lameter
2020-11-23 18:02         ` Marcelo Tosatti
2020-11-24 17:12         ` Vlastimil Babka
2020-11-24 19:52           ` Marcelo Tosatti
2020-11-27 15:48         ` Marcelo Tosatti
2020-11-28  3:49           ` [EXT] " Alex Belits
2020-11-30 18:18             ` Marcelo Tosatti
2020-11-30 18:29               ` Marcelo Tosatti
2020-12-03 22:47                 ` Alex Belits
2020-12-03 22:21               ` Alex Belits
2020-11-30  9:31           ` Christoph Lameter
2020-12-02 12:43             ` Marcelo Tosatti
2020-12-02 15:57             ` Thomas Gleixner
2020-12-02 17:43               ` Christoph Lameter
2020-12-03  3:17                 ` Thomas Gleixner
2020-12-07  8:08                   ` Christoph Lameter
2020-12-07 16:09                     ` Thomas Gleixner
2020-12-07 19:01                       ` Thomas Gleixner
2020-12-02 18:38               ` Marcelo Tosatti
2020-12-04  0:20                 ` Frederic Weisbecker
2020-12-04 13:31                   ` Marcelo Tosatti
2020-12-04  1:43               ` [EXT] " Alex Belits
2021-01-13 12:15                 ` [RFC] tentative prctl task isolation interface Marcelo Tosatti
2021-01-14  9:22                   ` Christoph Lameter
2021-01-14 19:34                     ` Marcelo Tosatti
2021-01-15 13:24                       ` Christoph Lameter [this message]
2021-01-15 18:35                         ` Alex Belits
2021-01-21 15:51                           ` Marcelo Tosatti
2021-01-21 16:20                             ` Marcelo Tosatti
2021-01-22 13:05                               ` Marcelo Tosatti
2021-02-01 10:48                             ` Christoph Lameter
2021-02-01 12:47                               ` Alex Belits
2021-02-01 18:20                               ` Marcelo Tosatti
2021-01-18 15:18                         ` Marcelo Tosatti
2020-11-24  5:02 ` [mm] e655d17ffa: BUG:using_smp_processor_id()in_preemptible kernel test robot

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=alpine.DEB.2.22.394.2101151311440.48145@www.lameter.com \
    --to=cl@linux.com \
    --cc=abelits@marvell.com \
    --cc=akpm@linux-foundation.org \
    --cc=bristot@redhat.com \
    --cc=frederic@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=mtosatti@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=willy@infradead.org \
    --subject='Re: [RFC] tentative prctl task isolation interface' \
    /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: link

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox