linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Kuan-Wei Chiu <visitorckw@gmail.com>
Cc: colyli@suse.de, kent.overstreet@linux.dev, msakai@redhat.com,
	corbet@lwn.net, mingo@redhat.com, acme@kernel.org,
	namhyung@kernel.org, akpm@linux-foundation.org,
	mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
	jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com,
	kan.liang@linux.intel.com, jserv@ccns.ncku.edu.tw,
	linux-kernel@vger.kernel.org, linux-bcache@vger.kernel.org,
	dm-devel@lists.linux.dev, linux-bcachefs@vger.kernel.org,
	linux-perf-users@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH 1/3] lib/min_heap: Introduce non-inline versions of min heap API functions
Date: Mon, 14 Oct 2024 10:13:58 +0200	[thread overview]
Message-ID: <20241014081358.GS17263@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20241013184703.659652-2-visitorckw@gmail.com>

On Mon, Oct 14, 2024 at 02:47:01AM +0800, Kuan-Wei Chiu wrote:
> All current min heap API functions are marked with '__always_inline'.
> However, as the number of users increases, inlining these functions
> everywhere leads to a significant increase in kernel size.
> 
> In performance-critical paths, such as when perf events are enabled and
> min heap functions are called on every context switch, it is important
> to retain the inline versions for optimal performance. To balance this,
> the original inline functions are kept, and additional non-inline
> versions of the functions have been added in lib/min_heap.c.

The reason it is all __always_inline is because then the whole
min_heap_callbacks thing can be constant propagated and the func->less()
etc calls become direct calls.

Doing out of line for this stuff, makes them indirect calls, and
indirect calls are super retarded expensive ever since spectre. But also
things like kCFI add significant cost to indirect calls.

Something that would be a trivial subtract instruction becomes this
giant mess of an indirect function call.

Given the whole min_heap thing is basically a ton of less() and swp()
calls, I really don't think this trade off makes any kind of sense.

  reply	other threads:[~2024-10-14  8:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-13 18:47 [PATCH 0/3] Enhance min heap API with non-inline functions and optimizations Kuan-Wei Chiu
2024-10-13 18:47 ` [PATCH 1/3] lib/min_heap: Introduce non-inline versions of min heap API functions Kuan-Wei Chiu
2024-10-14  8:13   ` Peter Zijlstra [this message]
2024-10-14  8:20     ` Peter Zijlstra
2024-10-14  9:41     ` Kuan-Wei Chiu
2024-10-17  3:26       ` Kent Overstreet
2024-10-17  9:55         ` Peter Zijlstra
2024-10-17 10:46           ` Kent Overstreet
2024-10-20  5:15     ` Kuan-Wei Chiu
2024-10-13 18:47 ` [PATCH 2/3] lib min_heap: Optimize min heap by prescaling counters for better performance Kuan-Wei Chiu
2024-10-13 18:47 ` [PATCH 3/3] Documentation/core-api: Add min heap API introduction Kuan-Wei Chiu
2024-10-14  8:55   ` Matthew Wilcox
2024-10-14 10:04     ` Kuan-Wei Chiu
2024-10-13 23:05 ` [PATCH 0/3] Enhance min heap API with non-inline functions and optimizations Kent Overstreet
2024-10-13 23:27   ` Kuan-Wei Chiu
2024-10-14  2:08     ` Kent Overstreet
2024-10-14  1:18   ` Coly Li
2024-10-14  1:23     ` Kent Overstreet

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=20241014081358.GS17263@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=colyli@suse.de \
    --cc=corbet@lwn.net \
    --cc=dm-devel@lists.linux.dev \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=jserv@ccns.ncku.edu.tw \
    --cc=kan.liang@linux.intel.com \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=msakai@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=visitorckw@gmail.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 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).