From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1A96E1FEFA9 for ; Mon, 21 Oct 2024 23:28:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729553303; cv=none; b=gxmQSzuUXi/yy+UVhhy66tgCLd0uiQ6nmXwkC5G7R5yT93qB7jnaDXwZTOcuB720YJ4P8OO8zOKt1wmkMjVXOawc2nEDVtP+ua00s1+H2pLvAVEh5ZEh7JR/DtboUCdogbqfQ2USLitM9NoqL2LkiKShxPl5N3lO9KA8KqoqaoE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729553303; c=relaxed/simple; bh=Zff+RWbA2FT88lk3jSWQqGKGPHCgQFk2oW3h5uX7IeA=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZA+3JNwPBWTftFjBnaLDse+/YpsmG8q96G0GoxsS76Ob/RLZFgO7MlkqItgR6reymbyZnbZYGvrmySh99VaFy8+ZAOF/bVV74PjM79UEH55PPUFrd4EacgLEeYn/XInJCbNo0IzRopiijOVqiokAQ7hBzInJ8lML4ANjzK39ToI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=HSu4SRoJ; arc=none smtp.client-ip=209.85.160.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="HSu4SRoJ" Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-4608dddaa35so150291cf.0 for ; Mon, 21 Oct 2024 16:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729553301; x=1730158101; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=s7g9rImT4RZY0eWuCNKQmXqLXLyfWgLkLWLrUC8CYD4=; b=HSu4SRoJsW8fiTfLNoPfWtmsST46EkuJlHkjES1+/95VKhqN6z816FGc4rm9uWnMb/ VJ3ppoKimFUlHoXvGXX2AfWR/jtFel0iuPDF1mhGnSCH11gSzLun0/FuCtIv7ignLa3G bogy8wfBdAbTEWcEIMLlAf/KLo1InWk7wFyJODV+4xpxwqWUafSk1xFxcIILHB14UZWF 0s8NWDbERo26AlnUM0qrUDhB+Y8GIq/lp1VwmK3qHBgTHLJFTZNEP6zf1AiRYR7H3OqA 12tseM+/pynF9DXeZM81eyu4n9NZ54i2Sm8PaedyrR32Fh+1ohfR+LMVZlKBCjYTiIJG 8xFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729553301; x=1730158101; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=s7g9rImT4RZY0eWuCNKQmXqLXLyfWgLkLWLrUC8CYD4=; b=ak2sy2tQaBs//NBVbJsG+sb1hKNUoW8pKgMSnzQq33t87irH8rsSi5k7dpuE4gYnpS uATkT3tlABl/iMey4+rGYi+ryED5uyzge+gohLSGymay8uQFVr+e60GRSivBtrMctolA Jb9s+N4araP+38p6Rn/e/UNHF9mf0ci7ljR1HPxZ5yhrd7nrygWacgmM1mAkHPK2/kty 2k3NezbKlM/v64wFhCixpayXM59Hliem7Gmb/0E8WJ1aTXCOXgVdNHorACmtr3sDwfcG nQPGpo98/G5ketrLuud/dCOcOqd403MBwX5uXY0sDAwf48qmz5RtaNsZ4hKyvALCVLgM ZbEg== X-Forwarded-Encrypted: i=1; AJvYcCVm6S9M3QasKZGX4sGF9HXxP6x882mKgE4YgAUGgFICGKxUsZhPIOY+leE8VWUUk2fxptbogeTzLuw=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1DxCW6pE86TZ7LMm0VVBFDaqnbK+IdNJcbCUF8Z/H9o6iuI6x W3wthI+Fe7eiFVYqUXea4N2RTVdUnLn8aV4H8LMxQGTaKxtg3YgIKreICArtZ7knCcEFkrHKZi1 z1aC3wt0wSkEmeSbm2aK8ley7gt1XNfMtKnXR X-Google-Smtp-Source: AGHT+IHlHILW/VtCMnIvRhHu4MUnVCebk8xwRyaArpHaBD/sb8cKitt+/rPJqdaQ95G0uL5u4b+WEZY+T68Iy0r6+2Q= X-Received: by 2002:a05:622a:303:b0:460:f093:f259 with SMTP id d75a77b69052e-46100b89943mr1430991cf.22.1729553300622; Mon, 21 Oct 2024 16:28:20 -0700 (PDT) Precedence: bulk X-Mailing-List: workflows@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20241014213342.1480681-1-xur@google.com> <20241014213342.1480681-6-xur@google.com> In-Reply-To: From: Rong Xu Date: Mon, 21 Oct 2024 16:28:07 -0700 Message-ID: Subject: Re: [PATCH v4 5/6] AutoFDO: Enable machine function split optimization for AutoFDO To: Masahiro Yamada Cc: Alice Ryhl , Andrew Morton , Arnd Bergmann , Bill Wendling , Borislav Petkov , Breno Leitao , Brian Gerst , Dave Hansen , David Li , Han Shen , Heiko Carstens , "H. Peter Anvin" , Ingo Molnar , Jann Horn , Jonathan Corbet , Josh Poimboeuf , Juergen Gross , Justin Stitt , Kees Cook , "Mike Rapoport (IBM)" , Nathan Chancellor , Nick Desaulniers , Nicolas Schier , "Paul E. McKenney" , Peter Zijlstra , Sami Tolvanen , Thomas Gleixner , Wei Yang , workflows@vger.kernel.org, Miguel Ojeda , Maksim Panchenko , x86@kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Sriraman Tallam , Krzysztof Pszeniczny Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 20, 2024 at 8:18=E2=80=AFPM Masahiro Yamada wrote: > > On Tue, Oct 15, 2024 at 6:33=E2=80=AFAM Rong Xu wrote: > > > > Enable the machine function split optimization for AutoFDO in Clang. > > > > Machine function split (MFS) is a pass in the Clang compiler that > > splits a function into hot and cold parts. The linker groups all > > cold blocks across functions together. This decreases hot code > > fragmentation and improves iCache and iTLB utilization. > > > > MFS requires a profile so this is enabled only for the AutoFDO builds. > > > > Co-developed-by: Han Shen > > Signed-off-by: Han Shen > > Signed-off-by: Rong Xu > > Suggested-by: Sriraman Tallam > > Suggested-by: Krzysztof Pszeniczny > > --- > > include/asm-generic/vmlinux.lds.h | 6 ++++++ > > scripts/Makefile.autofdo | 2 ++ > > 2 files changed, 8 insertions(+) > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vm= linux.lds.h > > index ace617d1af9b..20e46c0917db 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h > > @@ -565,9 +565,14 @@ defined(CONFIG_AUTOFDO_CLANG) > > __unlikely_text_start =3D .; = \ > > *(.text.unlikely .text.unlikely.*) = \ > > __unlikely_text_end =3D .; > > +#define TEXT_SPLIT = \ > > + __split_text_start =3D .; = \ > > + *(.text.split .text.split.[0-9a-zA-Z_]*) = \ > > + __split_text_end =3D .; > > #else > > #define TEXT_HOT *(.text.hot .text.hot.*) > > #define TEXT_UNLIKELY *(.text.unlikely .text.unlikely.*) > > +#define TEXT_SPLIT > > #endif > > > Why conditional? The condition is to ensure that we don't change the default kernel build by any means. The new code will introduce a few new symbols. > > > Where are __unlikely_text_start and __unlikely_text_end used? These new symbols are currently unreferenced within the kernel source tree. However, they provide a valuable means of identifying hot and cold sections of text, and how large they are. I think they are useful information. > > > > > > > > -- > Best Regards > Masahiro Yamada