From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 7F8DA313E13 for ; Fri, 16 Jan 2026 22:30:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768602621; cv=none; b=bzsLtfYwOrosmFneTbW7Y4n6Ybv2MSBnnxY9l9hkFDOrAi4SjFu88/I3aRIqWF7OAQGDTbPh85tswtNmi/XsptYizagoNjNvPch1GOKqSIe5bZch6MFRkrL2lZLDAQdVABp4v5cM2yhTSR/QXtMtX26S8vovSYfG79qo5q9qPwA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768602621; c=relaxed/simple; bh=dG/D69cqK/Ty2Ep6B4YLN1bPeHBFFiRmxFtpxPoYyew=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bvxWwnQNFJNxvVdBM75wOM4l8/CZAHPbmJVptLlECrGoVhbRFSZrrNyDjsX8C6ZcxcbmQUK3nXZEvSw4aT7rCf6gnJhS1tfHjK4l9vbaubZlE8lIY/oHE7OLhdzIsBdL+2OiupzhsKCXzwF6nbzVf78DDZmKyPiVMqmGz8n8BF0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TcKDICdo; arc=none smtp.client-ip=209.85.221.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TcKDICdo" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-43284ed32a0so1428545f8f.3 for ; Fri, 16 Jan 2026 14:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768602618; x=1769207418; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=lxK0gotd4uJBuq5yCuZa4Y0yPqnCu9xY2SR2B7d1Ka8=; b=TcKDICdoWExfE5BhoohKDTYDqMDlPUbZieR5kHLup65eobKkVHYHwxn+DNRXuCAYNl JJDjqKpxOpchPz9jA70ZO2viyQRMxXYwGgetOfxeorEseovUPJOwS99uOGjVHmpdAndn AxC8Av00sbVzRk55YZzf1+4nqXlqUex3PmevPCRtrJDDbVzNEAWIODuP9FSawV378Ict W/uyXpW9O2fQY2pyTgrXtC7zhQJIvYggXiAHWFiDZ6Z9l2rr/LUTmMP67J2IE79iSbiO Vv1Kox0Yroik7FQsu0bnVuOIosXzNxIJklLdBfn2UwV0fUH1qsjNL/YO+FSIApxxi/jP hb9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768602618; x=1769207418; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=lxK0gotd4uJBuq5yCuZa4Y0yPqnCu9xY2SR2B7d1Ka8=; b=fTnm1fnxiqnvxLewWGe7cJYLj2Sd/Hx4LgnAH8QHFoiSa7Patclc0VbnmOWpDzyqm9 lK8nJATewnFIYAbg6mYtbAx1OqRPoFoCWdmn5BiBi7drtW6c1rbWXnNltGItuHGVwuUL 14yzEsaiyaYEA2VTyuYg1z7KIbYJUQraq3sJg+Sdb+EWarWOTtaw5hkCP4u02VbdCLL2 8nGcCzPvC6ms0BFQGZpiz7QEtRCq7mTvq7bijsyLj8+Md5qWv+wkETfuICvA8CdVaMTA E2mP/M6aTStEX161JYAc3c8pAHKw+71+q9VGTC06u7QJ+jHdcbMkZ+Bm999V6kHPU3yl fD4A== X-Forwarded-Encrypted: i=1; AJvYcCWFI7+V6kefb55U0gx+Q6ynLugkcqkoOl94IKNooHrpWHFIDXXwFjCuK2c8nYJV3qiKTZj4YjPu8G0DzJA=@vger.kernel.org X-Gm-Message-State: AOJu0YxieF1m64FWC3oBWrmQGFXZpj7yZxcsYHQifBqoqoFKjmAKX93v pwQ2U9iL42udvKHul+ZGMVRDaz7VkK1vnjJgyNr2QSGHsqV1mKduWjx3 X-Gm-Gg: AY/fxX7jriWp7fb/hla2lx++3G8o7VGvUgkrbQBArLjHgo9p+AZAtPLEcr6J6k18DYI wGwr1d0qPLMCIMzvzcP4O6Uvekt/Y93RDmJ55BLWMy7Im5Ic5f/OamcoKr10qU6LDWR0mbUK3Xr YW7buz37+/9vWRlZvWduYD9FfSpt1b6fsUcXH91O8MiMkw3Qev0dIhFmkczqVAY+htKgQLFSpjT ydkuRABArDesFNQPj9E+F7iMU+ljPOXnYLa588IagN8djag1XMOUg6B0uWdvrlxCm0yyTZ1EHHS BPAAhnIYvbD9mdapfVbwOEOw1SBchwdG1Tdr9TlWSENCKrokHNzzFGdkJd8gKSYlTFbCzTAHqeq b1kF7fGWeVYGSEhtu9/UGwGjMr2f/rz+mbvQHg1j9RypHeFmLe3KlPoNuSCBaphlybFrpvLCTkf b5I8xCIXnipKOG4xKZ/QhFsZL18/wo+RCWT5olIX1W3JBvV5P6dF1w X-Received: by 2002:a05:6000:288b:b0:430:fa9a:767 with SMTP id ffacd0b85a97d-4356998ad3fmr5550380f8f.23.1768602617490; Fri, 16 Jan 2026 14:30:17 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435699272a0sm7655699f8f.17.2026.01.16.14.30.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 14:30:17 -0800 (PST) Date: Fri, 16 Jan 2026 22:30:15 +0000 From: David Laight To: Holger Dengler Cc: Eric Biggers , Ard Biesheuvel , "Jason A . Donenfeld" , Herbert Xu , Harald Freudenberger , linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org Subject: Re: [PATCH v1 1/1] lib/crypto: tests: Add KUnit tests for AES Message-ID: <20260116223015.60887d5d@pumpkin> In-Reply-To: References: <20260115183831.72010-1-dengler@linux.ibm.com> <20260115183831.72010-2-dengler@linux.ibm.com> <20260115204332.GA3138@quark> <20260115220558.25390c0e@pumpkin> <389595e9-e13a-42e3-b0ff-9ca0dd3effe3@linux.ibm.com> <20260116183744.04781509@pumpkin> <2d5c7775-de20-493d-88cc-011d2261c079@linux.ibm.com> <20260116194410.GA1398962@google.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 16 Jan 2026 21:55:04 +0100 Holger Dengler wrote: > On 16/01/2026 20:44, Eric Biggers wrote: ... > > The warm-up loops in the existing benchmarks are both for cache warming > > and to get the CPU frequency fast and fixed. It's not anything > > sophisticated, but rather just something that's simple and seems to > > works well enough across CPUs without depending on any special APIs. If > > your CPU doesn't do much frequency scaling, you may not notice a > > difference, but other CPUs may need it. > > Do you have a gut feeling how many iterations it takes to get the CPU speed > up? If it takes less than 50 iterations, it would be sufficient with the new > method. It may not matter what you do to get the cpu speed fixed. Looping calling ktime_get_ns() for 'long enough' should do it. That would be test independent but the 'long enough' very cpu dependent. The benchmarks probably ought to have some common API - even if it just in the kunit code. The advantage of counting cpu clocks is the frequency then doesn't matter as much - L1 cache miss timings might change. The difficulty is finding a cpu clock counter. Architecture dependent and may not exist (you don't want the fixed frequency 'sanitised' TSC). David