On 2019/11/8 17:25, Peter Zijlstra wrote:
On Fri, Nov 08, 2019 at 10:21:36AM +0100, Peter Zijlstra wrote:
On Fri, Nov 08, 2019 at 09:42:55AM +0800, Shile Zhang wrote:
Can sort{ex,orc}table() be ran concurrently? Do they want to be the same
(threaded) tool?
I think it is possible to do those sort work concurrently, likes deferred
memory init which is big boot time speed up.
But I don't know if the exception table and ORC unwind tables can be
deferred, due to those tables might be used in early boot time, for early
exception handling and early debugging. I'm not familiar with that.
I meant at link time, run both sorts concurrently such that we only have
to wait for the longest, instead of the sum of them.
They're not changing the same part of the ELF file, so it should be
possible to have one tool have multiple threads, each sorting a
different table.
Aside from the .ex_table and ORC there's also .jump_table that wants
sorting (see jump_label_sort_entries()).
Oh, and I'll be adding .static_call_sites soon, see:
https://lkml.kernel.org/r/20191007082708.013939311@xxxxxxxxxxxxx
(I should repost that)
That gives us 4 tables to sort which we can do concurrently in 4
threads.
I got your point now.
I'll try to rework the sort tool to sort all tables concurrently in one
tool with multiple-threads.
Thanks for your advice!
I agree that doing it at link time makes sense, I just hate to do all
this sorting in sequence and blowing up the link time. I don't build for
customers, I build for single use boot and linking _SUCKS_.
