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=-4.0 required=3.0 tests=BAYES_00,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 D0725C433C1 for ; Mon, 29 Mar 2021 13:32:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 91F3961938 for ; Mon, 29 Mar 2021 13:32:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231695AbhC2NcM (ORCPT ); Mon, 29 Mar 2021 09:32:12 -0400 Received: from mail-ej1-f54.google.com ([209.85.218.54]:40650 "EHLO mail-ej1-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229674AbhC2Nbk (ORCPT ); Mon, 29 Mar 2021 09:31:40 -0400 Received: by mail-ej1-f54.google.com with SMTP id u9so19460390ejj.7; Mon, 29 Mar 2021 06:31:39 -0700 (PDT) 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=KytxCMPWowD4rik3dQfwPYa5nzVpGWTaHqOIiMrFA+g=; b=kuqPKtuhHfuYrJS/R3dkx8XMpToTOb8T57yjI+/gr/e2EVStSpaRJxsVBemx8pE2iW 4pQrepGTmDQ1ujQBc4N5XKVqpirWlLzbItl1mIemeoSQz9OvrykUySE1tQAvJIYE3KVS hObVR5oMAivMBDO+Lkg6q8nm5mAFcJ+qWO4ckBoauLhRZJuylE+PtiwmT7fXdkOGaSDt e7jVg0VV/0PCnchudTrxZ3tJpkOl26OjKfTxZsrQFmZcVJMiY6jhDZVixc9helz7tvO9 VAKxWAoy92yXXxu5LqEx3if42HfQiUTgzl3/MVqlAEPkm3BAmLzZ3SoYNsWEGSIkxzix ZC5Q== X-Gm-Message-State: AOAM530P5IXTau65K2mdPsClPrtwChPAWP0OY8SsdnLNKlmYRdR/3hZU IQxN3fcfl/7Pl1bSoAJvFUWxCCW4eMSVGQIgBu+VI9BF X-Google-Smtp-Source: ABdhPJwF4ZWWoE8xAKqU0qrM/UkqqYjBcHhQlub0SOHqzAntJ28k3gIPtNZJjGOoePm8EyYlHKkGXAo0sRZ5ifCjXMs= X-Received: by 2002:a17:906:4055:: with SMTP id y21mr28073275ejj.507.1617024699011; Mon, 29 Mar 2021 06:31:39 -0700 (PDT) MIME-Version: 1.0 References: <20210221185637.19281-1-chang.seok.bae@intel.com> <20210221185637.19281-23-chang.seok.bae@intel.com> <871rc9bl3v.fsf@nanos.tec.linutronix.de> <87r1k0ck7o.ffs@nanos.tec.linutronix.de> In-Reply-To: <87r1k0ck7o.ffs@nanos.tec.linutronix.de> From: Len Brown Date: Mon, 29 Mar 2021 09:31:27 -0400 Message-ID: Subject: Re: [PATCH v4 22/22] x86/fpu/xstate: Introduce boot-parameters to control state component support To: Thomas Gleixner Cc: Andy Lutomirski , "Chang S. Bae" , Borislav Petkov , Ingo Molnar , X86 ML , "Brown, Len" , Dave Hansen , "Liu, Jing2" , "Ravi V. Shankar" , Linux Kernel Mailing List , Linux Documentation List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 27, 2021 at 6:20 PM Thomas Gleixner wrote: > What's the actual downside of issuing TILERELEASE conditionally > depending on prev->AMX INIT=0? Is it slooooow or what's the real > problem here? TILERELEASE is fast, so there should be no down-side to execute it. Indeed, checking whether you need to execute it or not will probably take longer than executing TILERELEASE. My point (perhaps academic) is that Linux should not have to know about TILERELEASE, or execute it. Re: running in the kernel with AMX INIT=0 AMX INIT=0 will prevent c6 on that core. I don't expect to see this in the syscall path, though if a user wanted to neglect to issue TILERELEASE, there is nothing forcing them to do so. It can certainly happen on the interrupt path, but on the interrupt patch I don't know if we can end up requesting c6 -- perhaps on a forced task migration? Re: frequency credits in the kernel with AMX INIT=0. It works exactly the same way as AMX INIT=1. That is to say, the frequency credits don't key off of AMX INIT, they key off of the actual use of the AMX execution unit, and the credits free up several orders of magnitude faster (both for AVX-512 and AMX) on this hardware as in previous generations. As a result, if we interrupt an AMX program, and run for an extended period of time in the kernel without XRESTOR to clear out his AMX INIT=0 state, that will not have any impact on the frequency we run inside the kernel any more than if he had AMX INIT=1 state. thanks, Len Brown, Intel Open Source Technology Center