linux-kernel - Re: [RFC PATCH v3 0/7] Speed booting by sorting ORC unwind tables at build time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 15 Nov 2019 16:24:52 +0800
From:   Shile Zhang <shile.zhang@...ux.alibaba.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H . Peter Anvin" <hpa@...or.com>,
        linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [RFC PATCH v3 0/7] Speed booting by sorting ORC unwind tables at
 build time



On 2019/11/15 15:25, Ingo Molnar wrote:
> * Shile Zhang <shile.zhang@...ux.alibaba.com> wrote:
>
>> Hi,
>>
>> I refactored the sortextable code and add ORC unwind tables sort
>> support, for kernel boot speedup by sorting kernel tables at build time
>> as much as possible.
>>
>> Followed Peter's suggestion, I put ORC tables sort into a separated
>> thread makes these tables sort concurrently. That helps to avoid
>> kernel's link time as possible.
> Could you please also measure how much boot time this saves,
> approximately, and how long it takes to do it at build time?

Thanks for your review!

I've tested on 2vcpu16GB VM (with 2.5GHz Xeon CPU), it can saves near 90ms.
And the new sorttable tool costs about 0.074s to do extable and orc 
tables sort,
on host with same CPU.
>
> Thanks,
>
> 	Ingo