From: Alex Belits <firstname.lastname@example.org> To: "email@example.com" <firstname.lastname@example.org> Cc: "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Subject: Re: [EXT] Re: [PATCH] mm: introduce sysctl file to flush per-cpu vmstat statistics Date: Thu, 3 Dec 2020 22:47:02 +0000 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20201130182909.GA19303@fuller.cnet> On Mon, 2020-11-30 at 15:29 -0300, Marcelo Tosatti wrote: > On Mon, Nov 30, 2020 at 03:18:58PM -0300, Marcelo Tosatti wrote: > > On Sat, Nov 28, 2020 at 03:49:38AM +0000, Alex Belits wrote: > > Hi Alex, > > Say, couldnt a notification from the trace-latency infrastructure, > notifying the admin that latency was exceeded due to interruptions > > x us (backtrace of x) + y us (backtrace of y) + z us (backtrace of z) > >= maxlatency us I believe, for performance and readability reasons we may want to replace backtrace with "cause" record that lists specific recognized cause of entering kernel (page fault, interrupt) with event-specific arguments that don't show up in backtrace, such as syscall, address, interrupt number, IPI call, timer. And then, optionally, a backtrace. It also should be taken into account that a backtrace is only useful if it is taken at the right point. We already know exactly what the backtrace is right after entering kernel, in task flags processing loop, or right before the exit. To determine anything important we have to do something (and possibly record a backtrace) in a specific handler, syscall, etc., but there we mostly care about the last function anyway. > > With an application which continue to handle traffic, be > as functional as the signal? (then again, don't know exactly what > you do in the signal handler...). If "the admin" is actually a manager process using an interface such as netlink, to collect this information from kernel. Isolated process wouldn't be able to use this interface until it knows that it exited isolation, because communication with kernel involves a syscall, so it will still need something -- notification through shared memory from the manager process, or possibly vdso, however touching vdso often may affect performance. There is one more piece of information that I want to record, remote and cause. Remote cause is whatever was set by _another_ CPU before calling this one, possibly with its backtrace. In that case backtrace is useful because we already know that we are sending the IPI, however what we need is to know, from where and how that was called. > > Could also count "enter kernel <-> exit kernel" window as in > interruption such a scheme. This is pretty much what the current patch does, conditionally on isolated state set in per-CPU flags, now that entry and exit hooks are in their places. If there will be tracing/logging done, timing can be collected there, and causes determined in a specific handler for them. We can add more flags for turning this mechanism on without full task isolation. -- Alex
next prev parent reply other threads:[~2020-12-03 22:47 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-17 16:28 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 [this message] 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 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [EXT] Re: [PATCH] mm: introduce sysctl file to flush per-cpu vmstat statistics' \ /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 for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).