Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2930500ybz; Sun, 19 Apr 2020 13:13:16 -0700 (PDT) X-Google-Smtp-Source: APiQypJ/gVbFCPxeId030ht3lDqNkAbmyLfYgqQTrZHC7xVAGr03N2bwUGMK6KTtkmeZoOPKWuuF X-Received: by 2002:a17:906:a857:: with SMTP id dx23mr13125427ejb.52.1587327196204; Sun, 19 Apr 2020 13:13:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587327196; cv=none; d=google.com; s=arc-20160816; b=EwOD2QHZC0ZGS+j/GJXgkMNe4f/hRS+e28+hQh351ZQwFLchsiXqTEY24fWX/HagYJ 4jySYyz9DLdoUF9omIdXY9i9xTYX+QNFtmpeLNt+yyYNMKRx+wHDq6hRzyEfpZezil0h MY41qOUhrchF/pFLW0syheZ66oTaVjhJlBwSSZ2q+GbqHeQjUaAXcFkB8Zx29OY2wZgv RKWtHKQQ8TSN47zDgQYHg+yxUJbQTcjlrhN5i+mDsN/8mo63d5DpgGfdLkjWl5W9+d81 gXeAsVxxEdVloFlHGd7UO4Ah/QNryjUQ/C4T4q3YiUeQpGsqqdlL6f/YY9jfQ/976YW7 NOQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=3A2WsTlKyCqcpEYGhy9Sxngw/Q073wgh7iBTbMSaLqw=; b=h20qIJdFwu4sjQQiJ2SQkC66CA5jCxnKLUQLTCyHE5jlW7HUUAXFfN41S/Bpcvmd8p QjUx3GTQF31/LNt44qQcd0YFZKdAFUQjaB53UFbWOuUzgeSLc9/Kj4x4qf3fEkXeBscq 9j5ao6AfTW95IEhDnzxBsfPj3Qes4BMa8bBF52bKZ/gO2IJO5p/03AJNk/a6WmLQy6ni E8n92KFaOPF0sAClL1Ff+TSX47Q39mufK0u5iI18Xw63hpU/EVwjT9DaEfEcI8ntc2Uq SFF27ExSnLjTac9egFuBznn6EprevhCqCprEpEhEhu6vyr3uWMrV/AfQOuPnbpL5ftDO Wx8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="YmWi4d/x"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z90si7949158ede.599.2020.04.19.13.12.52; Sun, 19 Apr 2020 13:13:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="YmWi4d/x"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725959AbgDSUJT (ORCPT + 99 others); Sun, 19 Apr 2020 16:09:19 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:20235 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725793AbgDSUJJ (ORCPT ); Sun, 19 Apr 2020 16:09:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587326947; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3A2WsTlKyCqcpEYGhy9Sxngw/Q073wgh7iBTbMSaLqw=; b=YmWi4d/xzv5mj1EMlV6d/mUXCiOTRAeixHJOnqk7JOsZCS0Iz0qbpsAjfPNZW5bPD5TgcQ 7E59117Rbss7eQq9qzpZogaUj8NGwJ8Xc+XyIgMUkDwDZZnKpG9V9BeRORFNCPqPYofwCZ y/NleT9cQg+nDNQtcyQkfV+5h0QJtbc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-260-ceLCFr1NMMeU4sliqNqURg-1; Sun, 19 Apr 2020 16:08:02 -0400 X-MC-Unique: ceLCFr1NMMeU4sliqNqURg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 67C3E1005510; Sun, 19 Apr 2020 20:08:01 +0000 (UTC) Received: from treble (ovpn-112-22.rdu2.redhat.com [10.10.112.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 110525DA76; Sun, 19 Apr 2020 20:07:59 +0000 (UTC) Date: Sun, 19 Apr 2020 15:07:58 -0500 From: Josh Poimboeuf To: Linus Torvalds Cc: Thomas Gleixner , Masahiro Yamada , Linux Kernel Mailing List , the arch/x86 maintainers , Peter Zijlstra Subject: Re: [GIT pull] perf/urgent for 5.7-rc2 Message-ID: <20200419200758.3xry3vn2a5caxapx@treble> References: <158730459860.31269.9496277256253823777.tglx@nanos.tec.linutronix.de> <158730460101.31269.5005570498545135614.tglx@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 19, 2020 at 11:56:51AM -0700, Linus Torvalds wrote: > On Sun, Apr 19, 2020 at 6:57 AM Thomas Gleixner wrote: > > > > please pull the latest perf/urgent branch from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-2020-04-19 > > So this one took me by surprise, because it only touched the 'tools' > subdirectory for the perf tool, and then when I did what I thought > would be a trivial test build, it re-built the whole kernel. > > And that made me go "Whaa?!?" > > After looking at it for a while (longer than I really want to admit), > I realized that it's because the headers are also shared with objtool, > and it all kind of made sense. > > I say "kind of" because I would have wished that objtool wouldn't > necessarily rebuild everything. Objtool is run against every .o file, and it's considered part of the toolchain, because of ORC generation and other reasons. If anything in the toolchain changes, everything gets rebuilt. It *is* kind of crude, because GCC shouldn't really need to run again. I don't know if there's a more refined way to handle that dependency. ccache helps :-) > So I'm wondering if there any way that objtool could be run at > link-time (and archive time) rather than force a re-build of all the > object files from source? We've actually been making progress in that direction. Peter added partial vmlinux.o support, for Thomas' noinstr validation. The problem is, linking is single-threaded so it ends up making the kernel build slower overall. So right now, we still do most things per compilation unit, and only do the noinstr validation at vmlinux.o link time. Eventually, especially with LTO, we'll probably end up moving everything over to link time. -- Josh