linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Will Deacon <will@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Matt Morehouse <mascasa@google.com>
Subject: Re: Process-wide watchpoints
Date: Thu, 12 Nov 2020 11:43:53 +0100	[thread overview]
Message-ID: <CACT4Y+ayRHua-6UyRwSM3=_oi+NkXbaO3-zZ1mpDmWonbybkeA@mail.gmail.com> (raw)
In-Reply-To: <20201112103125.GV2628@hirez.programming.kicks-ass.net>

On Thu, Nov 12, 2020 at 11:31 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Thu, Nov 12, 2020 at 08:46:23AM +0100, Dmitry Vyukov wrote:
>
> > for sampling race detection),
> > number of threads in the process can be up to, say, ~~10K and the
> > watchpoint is intended to be set for a very brief period of time
> > (~~few ms).
>
> Performance is a consideration here, doing lots of IPIs in such a short
> window, on potentially large machines is a DoS risk.
>
> > This can be done today with both perf_event_open and ptrace.
> > However, the problem is that both APIs work on a single thread level
> > (? perf_event_open can be inherited by children, but not for existing
> > siblings). So doing this would require iterating over, say, 10K
>
> One way would be to create the event before the process starts spawning
> threads and keeping it disabled. Then every thread will inherit it, but
> it'll be inactive.
>
> > I see at least one potential problem: what do we do if some sibling
> > thread already has all 4 watchpoints consumed?
>
> That would be immediately avoided by this, since it will have the
> watchpoint reserved per inheriting the event.
>
> Then you can do ioctl(PERF_EVENT_IOC_{MODIFY_ATTRIBUTES,ENABLE,DISABLE})
> to update the watch location and enable/disable it. This _will_ indeed
> result in a shitload of IPIs if the threads are active, but it should
> work.

Aha! That's the possibility I missed.
We will try to prototype this and get back with more questions if/when
we have them.
Thanks!

  reply	other threads:[~2020-11-12 10:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12  7:46 Process-wide watchpoints Dmitry Vyukov
2020-11-12 10:31 ` Peter Zijlstra
2020-11-12 10:43   ` Dmitry Vyukov [this message]
     [not found]     ` <CACT4Y+bW1gpv8bz0vswaVUt-OB07oJ3NBeTi+vchAe8TTWK+mg@mail.gmail.com>
     [not found]       ` <CACT4Y+ZsKXfAxrzJGQc5mJ+QiP5sAw7zKWtciS+07qZzSf33mw@mail.gmail.com>
2021-02-01  8:50         ` Dmitry Vyukov
2021-02-03 12:29           ` Peter Zijlstra
2021-02-03 12:49             ` Dmitry Vyukov
2021-02-03 12:50               ` Dmitry Vyukov
2021-02-03 13:37               ` Peter Zijlstra
2021-02-04  8:10                 ` Dmitry Vyukov
2021-02-04  9:38                   ` Peter Zijlstra
2021-02-04  9:54                     ` Dmitry Vyukov
2021-02-04 12:09                       ` Peter Zijlstra
2021-02-04 12:53                         ` Dmitry Vyukov
2021-02-04 13:10                           ` Peter Zijlstra
2021-02-04 13:35                             ` Dmitry Vyukov
2021-02-04 13:45                               ` Peter Zijlstra
2021-02-04 14:59                               ` Peter Zijlstra
2021-02-04 13:33                           ` Peter Zijlstra
2021-02-04 13:37                             ` Dmitry Vyukov
2021-02-04 13:06                         ` Peter Zijlstra
2021-02-03  5:38         ` Namhyung Kim
2021-02-04  8:10           ` Dmitry Vyukov
2021-02-03 12:22       ` Peter Zijlstra

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='CACT4Y+ayRHua-6UyRwSM3=_oi+NkXbaO3-zZ1mpDmWonbybkeA@mail.gmail.com' \
    --to=dvyukov@google.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mascasa@google.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=will@kernel.org \
    /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).