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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 502CEC433B4 for ; Sat, 1 May 2021 16:32:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 18E0B613F0 for ; Sat, 1 May 2021 16:32:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231426AbhEAQdg (ORCPT ); Sat, 1 May 2021 12:33:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230195AbhEAQdf (ORCPT ); Sat, 1 May 2021 12:33:35 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21D1AC06174A for ; Sat, 1 May 2021 09:32:44 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id n138so1759548lfa.3 for ; Sat, 01 May 2021 09:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MZW1EyHy79UfqUVwrUmwZE+wtdLBfVdkxB4jvLroyEk=; b=eFriZnXe6wAI8zO+VW8KKD055WxxPNqYoov2j/At6g9drhJwYeJQ7xKbZeKV/RLlbf PE1RAhRXVs9Ej+sgAh6Q/MZpQ5AydWNgOvFHdr/dp8MfG8eHRrZYGFBKbi7sDMYlXRlL R2gUVRB1wHwHx3W6mZ6ZUqqNyXrMQlLHLNs+A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MZW1EyHy79UfqUVwrUmwZE+wtdLBfVdkxB4jvLroyEk=; b=KRv/D+QI1RwRZ3aH+raVMnytoFUTydxqYlkKkqWjP/5AS6ofQR3O8KyHflWU07QCYX h4Sr7PvTSF2zNT/I2qO+SlV6DaaiCqgnoyq0UMfAayDQuT34DORxnSAZVHMZUySPeRth JcwGvZGuizFh7Hb/aQWZleDf4u8Q6a3ey+K9hy4/eopukVyu13SFtUkiTgfRRshVHY5F zwGsdWpKoR+y7X1mf97F2UHUrjd1M6Uj5Ccl627outo/LxMwM4lWoRBromorY8hA61Rs ORd8ExRCn8GNmxOL6In+IgalmUPPdutsquFjY76c6EI3hFHg9WgQ/q7pfw3g8wovcvzy ed6A== X-Gm-Message-State: AOAM533h/wI0le8A1VuC6yP1OOTp9nopzX1Ic5dcfPQDdjKJPD8m84// qIXZQp+MtbByvvgq0KJV+8owKd6hXTf1PcYq X-Google-Smtp-Source: ABdhPJyfsXkq925ukDsdmkQMd1bNWugb8LlsULg7x8Fa7/vCPdq0poh5TmliLEhSbeUeUUkQNzFmBQ== X-Received: by 2002:ac2:538b:: with SMTP id g11mr7095772lfh.108.1619886762316; Sat, 01 May 2021 09:32:42 -0700 (PDT) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id y22sm611387lfl.36.2021.05.01.09.32.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 May 2021 09:32:41 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id x20so1741208lfu.6 for ; Sat, 01 May 2021 09:32:41 -0700 (PDT) X-Received: by 2002:a05:6512:a90:: with SMTP id m16mr6986867lfu.201.1619886761106; Sat, 01 May 2021 09:32:41 -0700 (PDT) MIME-Version: 1.0 References: <1c5e05fa-a246-9456-ff4e-287960acb18c@redhat.com> In-Reply-To: <1c5e05fa-a246-9456-ff4e-287960acb18c@redhat.com> From: Linus Torvalds Date: Sat, 1 May 2021 09:32:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Very slow clang kernel config .. To: Tom Stellard Cc: Nick Desaulniers , Masahiro Yamada , Nathan Chancellor , Linux Kernel Mailing List , clang-built-linux , Fangrui Song , Serge Guelton , Sylvestre Ledru Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 30, 2021 at 8:33 PM Tom Stellard wrote: > > Yes, it's intentional. Dynamic linking libraries from other packages is > the Fedora policy[1], and clang and llvm are separate packages (in Fedora). Side note: I really wish Fedora stopped doing that. Shared libraries are not a good thing in general. They add a lot of overhead in this case, but more importantly they also add lots of unnecessary dependencies and complexity, and almost no shared libraries are actually version-safe, so it adds absolutely zero upside. Yes, it can save on disk use, but unless it's some very core library used by a lot of things (ie particularly things like GUI libraries like gnome or Qt or similar), the disk savings are often not all that big - and disk is cheap. And the memory savings are often actually negative (again, unless it's some big library that is typically used by lots of different programs at the same time). In this case, for example, it's true that a parallel build will be running possibly hundreds of copies of clang at the same time - and they'll all share the shared llvm library. But they'd share those same pages even if it wasn't a shared library, because it's the same executable! And the dynamic linking will actually cause a lot _less_ sharing because of all the fixups. We hit this in the subsurface project too. We had a couple of libraries that *nobody* else used. Literally *nobody*. But the Fedora policy meant that a Fedora package had to go the extra mile to make those other libraries be shared libraries, for actual negative gain, and a much more fragile end result (since those libraries were in no way compatible across different versions - so it all had to be updated in lock-step). I think people have this incorrect picture that "shared libraries are inherently good". They really really aren't. They cause a lot of problems, and the advantage really should always be weighed against those (big) disadvantages. Pretty much the only case shared libraries really make sense is for truly standardized system libraries that are everywhere, and are part of the base distro. [ Or, for those very rare programs that end up dynamically loading rare modules at run-time - not at startup - because that's their extension model. But that's a different kind of "shared library" entirely, even if ELF makes the technical distinction between "loadable module" and "shared library" be a somewhat moot point ] Linus