From: Peter Zijlstra <peterz@infradead.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Song Liu <song@kernel.org>,
"linux-modules@vger.kernel.org" <linux-modules@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"songliubraving@fb.com" <songliubraving@fb.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH/RFC] module: replace module_layout with module_memory
Date: Wed, 18 Jan 2023 16:07:17 +0100 [thread overview]
Message-ID: <Y8gLJYA3ibA8De58@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <154ed99c-5877-35f6-5e7d-9d7abada7d33@csgroup.eu>
On Tue, Jan 10, 2023 at 06:31:41AM +0000, Christophe Leroy wrote:
> Le 09/01/2023 à 21:51, Song Liu a écrit :
> > Do you mean one tree will cause addr_[min|max] to be inaccurate?
> >
>
> Yes at least. On powerpc you will have module text below kernel,
> somewhere between 0xb0000000 and 0xcfffffff, and you will have module
> data in vmalloc area, somewhere between 0xf0000000 and 0xffffffff.
>
> If you have only one tree, any address between 0xc0000000 and 0xefffffff
> will trigger a tree search.
The current min/max thing is tied to the tree because of easy update on
remove, but module-insert/remove is not a performance critical path.
So I think it should be possible to have {min,max}[TYPES] pairs. Either
brute force the removal -- using a linear scan of the mod->list to find
the new bounds on removal.
Or overengineer the whole thing and use an augmented tree to keep that
many heaps in sync during the update -- but this seems total overkill.
The only consideration is testing that many ranges in
__module_address(), this is already 2 cachelines worth of range-checks
-- which seems a little excessive.
(also, I note that module_addr_{min,max} are unused these days)
next prev parent reply other threads:[~2023-01-18 15:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-06 22:09 [PATCH/RFC] module: replace module_layout with module_memory Song Liu
2023-01-09 18:03 ` Christophe Leroy
2023-01-09 18:24 ` Song Liu
2023-01-09 20:51 ` Song Liu
2023-01-10 6:31 ` Christophe Leroy
2023-01-10 6:51 ` Song Liu
2023-01-18 15:07 ` Peter Zijlstra [this message]
2023-01-18 17:52 ` Song Liu
2023-01-10 18:31 ` Song Liu
2023-01-17 18:50 ` Song Liu
2023-01-18 7:40 ` Christoph Hellwig
2023-01-18 17:37 ` Song Liu
2023-01-18 21:52 ` Song Liu
2023-01-19 5:35 ` Christoph Hellwig
2023-01-19 8:29 ` Song Liu
2023-01-20 17:42 ` Song Liu
2023-01-23 6:57 ` Christoph Hellwig
2023-01-24 18:01 ` Song Liu
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=Y8gLJYA3ibA8De58@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=song@kernel.org \
--cc=songliubraving@fb.com \
--cc=tglx@linutronix.de \
/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.