All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joelaf@google.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: lttng-dev@lists.lttng.org,
	diamon-discuss@lists.linuxfoundation.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [diamon-discuss] [RELEASE] LTTng-modules 2.9.11, 2.10.8, 2.11.0-rc2 (Linux kernel tracer)
Date: Thu, 1 Nov 2018 16:33:47 -0700	[thread overview]
Message-ID: <CAJWu+ooEbjOXgVeq+g4MGEve9PTo7p7UUKjYYHhq-Wz6UbUhfg@mail.gmail.com> (raw)
In-Reply-To: <60988959.4070.1541112982406.JavaMail.zimbra@efficios.com>

On Thu, Nov 1, 2018 at 3:56 PM Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> Hi,
>
> This is a set of bugfix releases of the LTTng modules kernel tracer.
> It covers the three currently active lttng-modules branches: the
> 2.9 and 2.10 stable branches, as well as the 2.11 branch in release
> candidate cycle.
>
> Those releases add support for kernel 4.19.
>
> One important improvement is to prevent allocation of buffers larger
> than the available memory, which can cause the OOM killer to trigger.
> Even if the OOM killer end up having to trigger, the current OOM kill
> target is set to the current thread while allocating buffers.

This is interesting. Me and Steve were looking at exactly this issue
with the ftrace ring buffer a few months ago. Turns out that even
setting the OOM kill target may not be enough to prevent all OOMs. I
don't remember the reason why not, I'll have to dig out those threads
but that's what the -mm folks said at the time. I did remember vaguely
that I tested it and the kill target doesn't always get killed.. its
possible that something *other* parallel allocation can be victimized
AFAIR, even though the culprit is the kill target.

 - Joel

WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joelaf@google.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: diamon-discuss@lists.linuxfoundation.org,
	lttng-dev@lists.lttng.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [diamon-discuss] [RELEASE] LTTng-modules 2.9.11, 2.10.8, 2.11.0-rc2 (Linux kernel tracer)
Date: Thu, 1 Nov 2018 16:33:47 -0700	[thread overview]
Message-ID: <CAJWu+ooEbjOXgVeq+g4MGEve9PTo7p7UUKjYYHhq-Wz6UbUhfg@mail.gmail.com> (raw)
In-Reply-To: <60988959.4070.1541112982406.JavaMail.zimbra@efficios.com>

On Thu, Nov 1, 2018 at 3:56 PM Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> Hi,
>
> This is a set of bugfix releases of the LTTng modules kernel tracer.
> It covers the three currently active lttng-modules branches: the
> 2.9 and 2.10 stable branches, as well as the 2.11 branch in release
> candidate cycle.
>
> Those releases add support for kernel 4.19.
>
> One important improvement is to prevent allocation of buffers larger
> than the available memory, which can cause the OOM killer to trigger.
> Even if the OOM killer end up having to trigger, the current OOM kill
> target is set to the current thread while allocating buffers.

This is interesting. Me and Steve were looking at exactly this issue
with the ftrace ring buffer a few months ago. Turns out that even
setting the OOM kill target may not be enough to prevent all OOMs. I
don't remember the reason why not, I'll have to dig out those threads
but that's what the -mm folks said at the time. I did remember vaguely
that I tested it and the kill target doesn't always get killed.. its
possible that something *other* parallel allocation can be victimized
AFAIR, even though the culprit is the kill target.

 - Joel

  reply	other threads:[~2018-11-01 23:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01 22:56 [RELEASE] LTTng-modules 2.9.11, 2.10.8, 2.11.0-rc2 (Linux kernel tracer) Mathieu Desnoyers
2018-11-01 22:56 ` [diamon-discuss] " Mathieu Desnoyers
2018-11-01 23:33 ` Joel Fernandes [this message]
2018-11-01 23:33   ` Joel Fernandes
2019-03-19 17:34   ` Mathieu Desnoyers
2019-03-21 12:41     ` Joel Fernandes
2019-03-21 13:13       ` Steven Rostedt
2019-03-21 13:13         ` Steven Rostedt
2019-03-22 13:48         ` Joel Fernandes
2019-03-22 13:48           ` Joel Fernandes

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=CAJWu+ooEbjOXgVeq+g4MGEve9PTo7p7UUKjYYHhq-Wz6UbUhfg@mail.gmail.com \
    --to=joelaf@google.com \
    --cc=diamon-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lttng-dev@lists.lttng.org \
    --cc=mathieu.desnoyers@efficios.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.