linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alex Belits <abelits@marvell.com>
To: "mtosatti@redhat.com" <mtosatti@redhat.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"frederic@kernel.org" <frederic@kernel.org>,
	"pauld@redhat.com" <pauld@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"willy@infradead.org" <willy@infradead.org>,
	"cl@linux.com" <cl@linux.com>
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: <c6467137ac7bb8e7134c00e0dcf20890d395b486.camel@marvell.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





  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 \
    --in-reply-to=c6467137ac7bb8e7134c00e0dcf20890d395b486.camel@marvell.com \
    --to=abelits@marvell.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=frederic@kernel.org \
    --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: [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).