From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Martin KaFai Lau <martin.lau@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-perf-users@vger.kernel.org, Song Liu <song@kernel.org>,
bpf@vger.kernel.org, Blake Jones <blakejones@google.com>,
Chris Li <chriscli@google.com>, Jiri Olsa <jolsa@kernel.org>
Subject: Re: [PATCH] perf lock contention: Do not use BPF task local storage
Date: Wed, 23 Nov 2022 10:49:54 -0300 [thread overview]
Message-ID: <Y34lAgJzG1DvUFXw@kernel.org> (raw)
In-Reply-To: <dea8c3c5-0739-58c1-9a88-b989878a9b8f@linux.dev>
Em Mon, Nov 21, 2022 at 09:32:56AM -0800, Martin KaFai Lau escreveu:
> On 11/18/22 11:01 AM, Namhyung Kim wrote:
> > It caused some troubles when a lock inside kmalloc is contended
> > because task local storage would allocate memory using kmalloc.
> > It'd create a recusion and even crash in my system.
> >
> > There could be a couple of workarounds but I think the simplest
> > one is to use a pre-allocated hash map.
>
> Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
Thanks, applied.
- Arnaldo
> > We could fix the task local storage to use the safe BPF allocator,
> > but it takes time so let's change this until it happens actually.
>
> I also got another report on the kfree_rcu path. I am also looking into
> this direction on using the BPF allocator.
--
- Arnaldo
next prev parent reply other threads:[~2022-11-23 13:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 19:01 [PATCH] perf lock contention: Do not use BPF task local storage Namhyung Kim
2022-11-21 17:32 ` Martin KaFai Lau
2022-11-23 13:49 ` Arnaldo Carvalho de Melo [this message]
2023-01-09 20:56 ` Namhyung Kim
2023-01-09 21:22 ` Martin KaFai Lau
2023-01-09 22:25 ` Namhyung Kim
2023-01-10 3:29 ` Hou Tao
2023-01-10 6:29 ` Martin KaFai Lau
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=Y34lAgJzG1DvUFXw@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=blakejones@google.com \
--cc=bpf@vger.kernel.org \
--cc=chriscli@google.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=song@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 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.