Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C495C742A7 for ; Wed, 8 Mar 2023 06:13:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229850AbjCHGNp (ORCPT ); Wed, 8 Mar 2023 01:13:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbjCHGNm (ORCPT ); Wed, 8 Mar 2023 01:13:42 -0500 Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4740B8EA20 for ; Tue, 7 Mar 2023 22:13:41 -0800 (PST) Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-536c02c9dfbso286846897b3.11 for ; Tue, 07 Mar 2023 22:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1678256020; 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=QiAc6iDNiFMAbN7UHWJQSh1sRq4ZHLyQcfVCvWd6xRw=; b=mep4iLM3eL4eFhiOCsS/C/HyLs4cXs6DifeXxcMOrrqxzXDttbjZu2izHtUGbdLycD hFA4+52CYusknxCEHXr2mloOTKwyu5QA8F3r9OvIswiOxosDQ4380j4kd+v63LSpZniQ 1pT0iekZ7dxQQRXNs7gN4ZukO00mYjP/I4rsZq9mWxfdsv67AT5QUWANBSxZTK5lygkh gq7Dlt2hjG2JuTLfJMO++9lo3RMfbgTwzfhb7+p+CboPIzvnZJBIHkwLszTwNYdPDUPE eZxeVht1nkAUswvVLIApysmhwPgYj09UbTXAsQB3z3iWgNWYLg2Fgkpjf6T/H+6LD7Dr Kcfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678256020; 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=QiAc6iDNiFMAbN7UHWJQSh1sRq4ZHLyQcfVCvWd6xRw=; b=dcLFJBYDhMiahw+NX4ct26jlpKv0QN5SMZDVhZQDRqssgKZOHuaEjuPyA3MnzJSy0x bU8FZKsIC+F9zbu5v2IkhKAHvpa9XdnFPgL38W+r6k5yFx/q9MvThNaqYe9b61EqPco9 4Nk7HL6ohBmRsq5U38LL8TaCy6yU09bmpaPlzJyQK31ktechGp3jYfz8rD7lqodWb1rR cIfc/ZlhZdbyHYA0HOH656t+LtErtghoUJBJTtV6iSLd1aafVrA6Anb0/Wmbq32qPLe2 ax2XyqyssJvan6NOaqA7vSYfDOxKADJNIb5CqyVnDlbLV2GYcr+l6GVgpKRomAbei0sp W7jA== X-Gm-Message-State: AO0yUKVAmkxLVyaFWMYcGIKiWDPRXbjH1KwIlfvXcccudUgFg7CX9obr OLZ1HDQdGjub0PMR9PWHiSeOuZlg1lXw2eImUt47xw== X-Google-Smtp-Source: AK7set9UbRfrxNxvgobWGUcgdwtDtWG8t/xs600BkL3DO9PrcoHUe3E4qN7u6XXOYIq6o2g3mGjHmvLGAGNz1IbbWf4= X-Received: by 2002:a81:a9c8:0:b0:53c:6fda:835f with SMTP id g191-20020a81a9c8000000b0053c6fda835fmr10410255ywh.0.1678256019925; Tue, 07 Mar 2023 22:13:39 -0800 (PST) MIME-Version: 1.0 References: <20230303231133.1486085-1-eranian@google.com> <20230306120106.GE1267364@hirez.programming.kicks-ass.net> <20230307113545.GB2017917@hirez.programming.kicks-ass.net> <20230307184315.GS25951@gate.crashing.org> In-Reply-To: From: Stephane Eranian Date: Tue, 7 Mar 2023 22:13:27 -0800 Message-ID: Subject: Re: [PATCH] x86/resctrl: avoid compiler optimization in __resctrl_sched_in To: Linus Torvalds Cc: Jakub Jelinek , Segher Boessenkool , Peter Zijlstra , Nick Desaulniers , linux-kernel@vger.kernel.org, tony.luck@intel.com, reinette.chatre@intel.com, fenghua.yu@intel.com, peternewman@google.com, james.morse@arm.com, babu.moger@amd.com, ananth.narayan@amd.com, vschneid@redhat.com, Nathan Chancellor , clang-built-linux , Borislav Petkov , "H. Peter Anvin" , linux-toolchains@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 7, 2023 at 1:06=E2=80=AFPM Linus Torvalds wrote: > > On Tue, Mar 7, 2023 at 12:54=E2=80=AFPM Linus Torvalds > wrote: > > > > I think the problem is that the code is disgusting and > > horrible in multiple ways: > > > > (a) it shouldn't define and declare a static function in a header file > > > > (b) the resctrl_sched_in() inline function is misdesigned to begin wit= h > > Ok, so here's a *ttoally* untested and mindless patch to maybe fix > what I dislike about that resctl code. > > Does it fix the code generation issue? I have no idea. But this is > what I would suggest is the right answer, without actually knowing the > code any better, and just going on a mindless rampage. > > It seems to compile for me, fwiw. > On Tue, Mar 7, 2023 at 3:01=E2=80=AFPM Nick Desaulniers wrote: > > On Tue, Mar 7, 2023 at 2:56=E2=80=AFPM Linus Torvalds > wrote: > > > > On Tue, Mar 7, 2023 at 2:03=E2=80=AFPM Nick Desaulniers wrote: > > > > > > Sounds like Stephane is going to re-run the internal tests he used to > > > discover the issue with your diff applied, if you don't mind holding > > > out for another Tested-by tag. EOM > > > > Ack. I am in no hurry. > > > > In fact, I'd prefer to just get the patch sent back to me with a > > commit message too, if somebody has the energy. I don't need the > > credit for a trivial thing like that. > > Sure, then maybe Stephane you can supply a v2 with updated commit message= and a > > Suggested-by: Linus Torvalds > I verified Linus' patch on my test case on AMD Zen3 and it works as expected, i.e., the limit is enforced. I had tried a similar approach myse= lf as well and it worked. I think passing the task pointer is the proper approach because we are in a sched_in routine and I would expect the task scheduled in to be passed as argument instead of having the function retrieve it from the current pointer. Thanks. Tested-by: Stephane Eranian > Linus