From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDEF7C5DF60 for ; Fri, 8 Nov 2019 09:21:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AED992178F for ; Fri, 8 Nov 2019 09:21:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ZiltVDzS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730812AbfKHJV6 (ORCPT ); Fri, 8 Nov 2019 04:21:58 -0500 Received: from merlin.infradead.org ([205.233.59.134]:41290 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726987AbfKHJV6 (ORCPT ); Fri, 8 Nov 2019 04:21:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d2mnXLzuXoufwijTVQq+z5+pvPRW/Sj5TTUKwZsS/cI=; b=ZiltVDzSwqIvTlgz/TP1DaA0X Cult2Ymj8fBks1Ywqt2+N4TwdW+1FKNvH+OTOgDcIIwFI6zfNFgIrS83eVCH/U6Cn/hU9I8zqZx6t Rh5uxJhlV6hggCUtdBcCXz7SP7g0BeZuELIilicLy/oloAotwhdHZykFfOo3g3TMPR0484HKBLtdv WVLzPoMpOidif53Oh7SjCrWpPAKMsubuX8+FHofxy0AZft5GEAleX9otrd9hM5sqHWKrPhtaFkxl8 holUSCGcrmhmX6lDpKz/foA4nhwc/RaAHciCQCqUd+mQPorwxk0P27I/Ht1kRssDXWWihwhVBVE8P lDgmgCgkQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1iT0SZ-0006Wi-Pl; Fri, 08 Nov 2019 09:21:39 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 46FEF300489; Fri, 8 Nov 2019 10:20:31 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 123172022B9E1; Fri, 8 Nov 2019 10:21:36 +0100 (CET) Date: Fri, 8 Nov 2019 10:21:36 +0100 From: Peter Zijlstra To: Shile Zhang Cc: Masahiro Yamada , Michal Marek , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Josh Poimboeuf , x86@kernel.org, "H . Peter Anvin" , linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org Subject: Re: [RFC PATCH 0/4] Speed booting by sorting ORC unwind tables at build time Message-ID: <20191108092136.GH4114@hirez.programming.kicks-ass.net> References: <20191107143205.206606-1-shile.zhang@linux.alibaba.com> <20191107152244.GD4114@hirez.programming.kicks-ass.net> <85abe498-f241-4752-81b5-6c0314f5a1e8@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85abe498-f241-4752-81b5-6c0314f5a1e8@linux.alibaba.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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()). 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_.