[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <61daf7e0-049c-0338-03a6-472694def181@huawei.com>
Date: Mon, 14 Nov 2022 09:25:43 +0800
From: "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
To: Luis Chamberlain <mcgrof@...nel.org>,
Nick Alcock <nick.alcock@...cle.com>, <rostedt@...dmis.org>
CC: Josh Poimboeuf <jpoimboe@...nel.org>,
Jiri Kosina <jikos@...nel.org>,
Miroslav Benes <mbenes@...e.cz>,
Petr Mladek <pmladek@...e.com>,
Joe Lawrence <joe.lawrence@...hat.com>,
<live-patching@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Jiri Olsa <jolsa@...nel.org>,
Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>,
<linux-modules@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>,
David Laight <David.Laight@...lab.com>
Subject: Re: [PATCH v8 0/9] kallsyms: Optimizes the performance of lookup
symbols
On 2022/11/13 10:55, Luis Chamberlain wrote:
> On Sat, Nov 12, 2022 at 06:44:26PM -0800, Luis Chamberlain wrote:
>> On Wed, Nov 02, 2022 at 04:49:12PM +0800, Zhen Lei wrote:
>>> v7 --> v8:
>>> Sort the symbols by name and implement kallsyms_lookup_name() using a binary
>>> search. The performance is more than 20 times higher than that of v7. Of course,
>>> the memory overhead is also extended to (3 * kallsyms_num_syms) bytes. Discard
>>> all implementations of compression and then comparison in v7.
>>>
>>> In addition, all sparse warnings about kallsyms_selftest.c are cleared.
>>
>> Awesome work, I can't find a single thing I hate about this, but my
>> biggest conern is the lack of testing so I'm going to merge this to
>
> Sorry finished the email too fast, I just wanted to add Nick to the
> thread as his work does tons of changes on scripts/kallsyms.c.
>
> I was saying -- I'm just concern with the lack of testing so I have merged
> this to modules-next and see what explodes over the next few weeks.
> I'm also happy to drop this from modules-next and have it go through
> the livepatching tree instead, but given Nick's work is dedicated
> towards modules and it also touches on scripts/kallsyms.c a lot, to
> avoid conflicts it felt best to merge that to modules for now in case
> his changes get merged during the next merge window.
>
> Let me know what folks prefer.
>
> Obviously, if testing blows up we can drop the series.
>
> Zhen, wouldn't ftrace benefit from the same
> s/kallsyms_on_each_symbol/kallsyms_on_each_match_symbol ?
ftrace uses regular matching, so it cannot be replaced.
>
> Luis
> .
>
--
Regards,
Zhen Lei
Powered by blists - more mailing lists