linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Vagin <avagin@gmail.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Andrei Vagin <avagin@google.com>,
	Kees Cook <keescook@chromium.org>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org,
	Christian Brauner <brauner@kernel.org>,
	Chen Yu <yu.c.chen@intel.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Peter Oskolkov <posk@google.com>,
	Tycho Andersen <tycho@tycho.pizza>,
	Will Drewry <wad@chromium.org>,
	Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: [PATCH 4/6] seccomp: add the synchronous mode for seccomp_unotify
Date: Sun, 9 Apr 2023 23:59:35 -0700	[thread overview]
Message-ID: <CANaxB-wykCH+2fgrwBNe2BkTmEJpZjhsFBekiS_qaQHz4vYt8Q@mail.gmail.com> (raw)
In-Reply-To: <CALCETrUB_rCCBa9TPt+7x0MBfKP9L5e8JXva-rDzE3B-AGEzNA@mail.gmail.com>

On Wed, Apr 5, 2023 at 8:42 PM Andy Lutomirski <luto@kernel.org> wrote:
>
> On Tue, Mar 7, 2023 at 11:32 PM Andrei Vagin <avagin@google.com> wrote:
> >
> > seccomp_unotify allows more privileged processes to do actions on behalf
> > of less privileged processes.
> >
> > In many cases, the workflow is fully synchronous. It means a target
> > process triggers a system call and passes controls to a supervisor
> > process that handles the system call and returns controls to the target
> > process. In this context, "synchronous" means that only one process is
> > running and another one is waiting.
> >
> > There is the WF_CURRENT_CPU flag that is used to advise the scheduler to
> > move the wakee to the current CPU. For such synchronous workflows, it
> > makes context switches a few times faster.
> >
> > Right now, each interaction takes 12µs. With this patch, it takes about
> > 3µs.
>
> This is great, but:
>
> >
> > This change introduce the SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP flag that
> > it used to enable the sync mode.
>
> Other than being faster, what does this flag actually do in terms of
> user-visible semantics?

In short, the process handling an event wakes up on the same cpu where the
process that triggered the event has been running. Knowing this fact, the user
can understand when it is appropriate to use this flag.

Let's imagine that we have two processes where one calls syscalls (the
target) and another one handles these syscalls (the supervisor). In this case,
the user should see that both processes are running on the same cpu.

If we have one target process and one supervisor process, they synchronously
swap with each other and don't need to run on cpu concurrently.  But
it becomes more
complicated if one supervisor handles a group of target processes. In this
case, setting the SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP flag depends on the
frequency of events. If the supervisor often has pending events (doesn't sleep
between events), it is better to unset the flag or add more supervisor
processes.

Thanks,
Andrei

  reply	other threads:[~2023-04-10  6:59 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08  7:31 [PATCH 0/6 v5 RESEND] seccomp: add the synchronous mode for seccomp_unotify Andrei Vagin
2023-03-08  7:31 ` [PATCH 1/6] seccomp: don't use semaphore and wait_queue together Andrei Vagin
2023-03-08  7:31 ` [PATCH 2/6] sched: add WF_CURRENT_CPU and externise ttwu Andrei Vagin
2023-04-08  3:20   ` Chen Yu
2023-04-10  4:56     ` Andrei Vagin
2023-04-10 17:27       ` Andy Lutomirski
2023-04-12 19:38         ` Andrei Vagin
2023-04-10 18:16       ` Chen Yu
2023-04-11  1:50         ` Chen Yu
2023-04-17 19:24         ` Andrei Vagin
2023-03-08  7:31 ` [PATCH 3/6] sched: add a few helpers to wake up tasks on the current cpu Andrei Vagin
2023-04-26 14:43   ` Bernd Schubert
2023-04-26 18:52   ` Andrei Vagin
2023-04-26 19:35     ` Bernd Schubert
2023-04-26 20:57       ` Bernd Schubert
2023-03-08  7:31 ` [PATCH 4/6] seccomp: add the synchronous mode for seccomp_unotify Andrei Vagin
2023-04-06  3:42   ` Andy Lutomirski
2023-04-10  6:59     ` Andrei Vagin [this message]
2023-04-10 20:53       ` Andy Lutomirski
2023-03-08  7:32 ` [PATCH 5/6] selftest/seccomp: add a new test for the sync mode of seccomp_user_notify Andrei Vagin
2023-03-08  7:32 ` [PATCH 6/6] perf/benchmark: add a new benchmark for seccom_unotify Andrei Vagin
2023-09-08 17:35   ` [PATCH] perf/benchmark: Fix ifdef in header file uapi/asm/unistd_32.h Vijayendra Suman
2023-09-08 17:38     ` Andrei Vagin
2023-09-08 18:18     ` Tycho Andersen
2023-10-17  8:24   ` [PATCH 6/6] perf/benchmark: add a new benchmark for seccom_unotify Jiri Slaby
2023-03-21 18:19 ` [PATCH 0/6 v5 RESEND] seccomp: add the synchronous mode for seccomp_unotify Andrei Vagin
2023-03-27 10:27 ` Peter Zijlstra
2023-04-03 18:32   ` Andrei Vagin
2023-04-06  3:19     ` Kees Cook
2023-06-28 18:44       ` Andrei Vagin
2023-06-28 23:32         ` Kees Cook
  -- strict thread matches above, loose matches on Subject: below --
2023-02-02  3:04 [PATCH 0/6 v5] " Andrei Vagin
2023-02-02  3:04 ` [PATCH 4/6] " Andrei Vagin
2023-01-24 23:41 [PATCH 0/6 v4] " Andrei Vagin
2023-01-24 23:41 ` [PATCH 4/6] " Andrei Vagin

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=CANaxB-wykCH+2fgrwBNe2BkTmEJpZjhsFBekiS_qaQHz4vYt8Q@mail.gmail.com \
    --to=avagin@gmail.com \
    --cc=avagin@google.com \
    --cc=brauner@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=posk@google.com \
    --cc=tycho@tycho.pizza \
    --cc=vincent.guittot@linaro.org \
    --cc=wad@chromium.org \
    --cc=yu.c.chen@intel.com \
    /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
Be 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).