Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <75a6faa29066960a74e7b2c60a7ae6acfd1893ab.camel@linux.intel.com>
Subject: Re: [PATCH] crypto: x86/sha512 - load based on CPU features
From:   Tim Chen <tim.c.chen@linux.intel.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>,
        "Elliott, Robert (Servers)" <elliott@hpe.com>
Cc:     Taehee Yoo <ap420073@gmail.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "Kani, Toshi" <toshi.kani@hpe.com>,
        "Wright, Randy (HPE Servers Linux)" <rwright@hpe.com>
Date:   Tue, 30 Aug 2022 10:40:40 -0700
In-Reply-To: <Ywg1fKiTGyNk78tB@gondor.apana.org.au>
References: <20220813230431.2666-1-elliott@hpe.com>
         <Yv9ubekvQiL3UGwd@gondor.apana.org.au>
         <MW5PR84MB18425E5211BD4EAF09D0CE3EAB6C9@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>
         <MW5PR84MB18426EBBA3303770A8BC0BDFAB759@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>
         <Ywg1fKiTGyNk78tB@gondor.apana.org.au>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Fri, 2022-08-26 at 10:52 +0800, Herbert Xu wrote:
> On Fri, Aug 26, 2022 at 02:40:58AM +0000, Elliott, Robert (Servers) wrote:
> > Suggestion: please revert the sha512-x86 patch for a while.
> 
> This problem would have existed anyway if the module was built
> into the kernel.
> 
> > Do these functions need to break up their processing into smaller chunks
> > (e.g., a few Megabytes), calling kernel_fpu_end() periodically to 
> > allow the scheduler to take over the CPUs if needed? If so, what
> > chunk size would be appropriate?
> 
> Yes these should be limited to 4K each.  It appears that all the
> sha* helpers in arch/x86/crypto have the same problem.
> 

I think limiting chunk to 4K is reasonable to prevent the CPU from being hogged by
the crypto code for too long.

Tim