From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.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 ABC32258CE7 for ; Fri, 30 Jan 2026 09:02:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769763747; cv=none; b=eZX9D/OUyPn0zp1VRuZibQ0r6bzX+8+72Am65xGOXDDXWhINiE5f0UwIyALjSxXD7Ip9cHhtILYqS2O9n0em9nVnhrO/uNNJFG09WrQcnFKl87nFQJnBkdEJ9sIKYSqwdX2pE3kYWFqr9IJBJeSiqrMibuQxm38bLBPK1Bal/QQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769763747; c=relaxed/simple; bh=O33+enz5tpNE+J5nE0JtBDWXLANIOIqEo0HTcsLFGAM=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mBLR1t9n+RwJfBXReGZ2K8cnu2cCjL5eh56iYL91X/m3F74+v/gonNNZu0PSBRfLZSVp41+7PG/OqFKRj8kWC2vsSKYEr2Nf5JnUUQCIMGPIbQ5AGoi0uhG4chrAY4DgHTn2f9rGiF/L61FeiQRc7a6Mer4beT92bWtz5YhDuuk= 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=PGTUextt; arc=none smtp.client-ip=209.85.128.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="PGTUextt" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-47ee937ecf2so15427595e9.0 for ; Fri, 30 Jan 2026 01:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769763744; x=1770368544; 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=t/aasGTleW9HbxCBWNULoHNGZ2JTbZdMTfhlS4qOyJI=; b=PGTUexttCJOM4woNQv/CiwjCerJsVUtSGvukUNMUsOfZ0z4tOqW3A51aNc5CqQtLkb 4drcnotlix26T41NbGSP4I/FO3hXfoyNWh/Lv2WxzYRm6UMsSD6PE/8N0Q+SfY0s/PLh 2Ond/rY4jYeI2MkjVNBYWfJK7SUumnWO00yMZo+1hciiogkSXPs7PIIDJnWh5Q9Ngk0x l/vIqFpQS3YwfyRTbdaStFozBP+vjnpzwkZMAxnRn0oWAir8fAr9saj9L0PmZU5fBG22 N6RiZC2eFfIJh8HW4uy6ZZw5yi9/9X6LhxfP8iC+ZhgtHstRa9mXODAiRyFjuUTRL59R gdRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769763744; x=1770368544; 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=t/aasGTleW9HbxCBWNULoHNGZ2JTbZdMTfhlS4qOyJI=; b=mUDYXb5oTWMuTXC1oSRDV3ThXFFcn87HScpJTLl7EctDjGBfmh2Dap8LR/Qt6aAmZ1 AQzI+yWbE3S2zZuxXU0DieEW52+m+0opURjoRH0gHWEC11pIew9FIySuYF/M18IFB5u9 /uKllxo4adO6bx70kN44wOOJE6Xb1AgWCiMqxRCFcByNvlR/khSP1rR9vZodmYGwPu6B 4GsBWB4ipCS29aApi4lxEeLAT1oH9N9QMyfi6sbnCG5zEHzk4+X/BJ+sFDjgsOgTfpyv tqyKVF1RAp25vSkSUFb7iwRsPeIoVFCfA36hj/aDZ41ekHfomOmAsC1Xa1YgqVMszxyf femQ== X-Gm-Message-State: AOJu0YxhpBN9fL8k/tMlCuY5T8hmIGwpIPOqEGnH9JOdHKNTkuHcx4pb 1/T/bBcd1WPa1Dsskd+p8qBZWwjs5cYDiXnU26u3mvOPrbBiHTJYr9vD7zn2XA== X-Gm-Gg: AZuq6aKdLsibfJuyxFERjctOt9hYVuDLoJQKhlX3rypWbo+8HssJBvYtS0pMbDWHznX ZqOpZwhnSq9HRYQTigx3PRQSun6gpCDhoskiLCeAXW1XyzSIsFwIYZNpEvCRtxNRIBLeT32XMOi 7Nws7mCPmQ/relAxg9BDODo/EK/12z18XFR6+0q1B479NJyuI68ifI9UtOJjWTStjIqSr2XmqcY OLzKoLArne1NyM5LhArjHJzVvK/Xws4MDjc5xy03MKPWVCO1fDcPZicpv001zG5iTKUS0mD0kcx qvqFKpr+2jys2XhW6RlrvC57RDmSB834W7MxoqsOO11VvR/9lJJ4pBkNdXPEwzKn2/kFLjoZBLI uplfB4NlPLSQ7SEkKcQxkO23ZocAJ8MCvwt4lreVjW45X8p4439X/YdC+bIwbPMCJnu2Laa6gEC wYtH25Yawd3SKU8u/2yBkUdeTBPnpJr1dEU+rAWDkf/FeQIHHO1TjQ X-Received: by 2002:a05:600c:4e91:b0:47f:1332:e5f with SMTP id 5b1f17b1804b1-480829b5cfamr79468975e9.12.1769763743886; Fri, 30 Jan 2026 01:02:23 -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 5b1f17b1804b1-482dbd3953esm18676595e9.4.2026.01.30.01.02.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jan 2026 01:02:23 -0800 (PST) Date: Fri, 30 Jan 2026 09:02:22 +0000 From: David Laight To: Matteo Croce Cc: linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH v2] KUnit: memcpy: add benchmark Message-ID: <20260130090222.658adbe4@pumpkin> In-Reply-To: <20260129234539.18513-1-teknoraver@meta.com> References: <20260129234539.18513-1-teknoraver@meta.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, 30 Jan 2026 00:45:39 +0100 Matteo Croce wrote: > Add optional benchmarks for memcpy() and memmove() functions. > Each benchmark is run twice: first with buffers aligned and then with > buffers unaligned, to spot unaligned accesses on platforms where they > have a noticeable performance impact. ... > +#ifdef CONFIG_MEMCPY_KUNIT_BENCHMARK > + > +#define COPY_SIZE (4 * 1024 * 1024) That is far too big. You are timing data-cache loads from memory, not memcpy(). To avoid cache misses you probably want to keep the size below 1k. It is also worth timing short and very short transfers (maybe 2 and 16 bytes) because the fixed overhead can matter more than the transfer speed. The difference between 256 and 1024 bytes is enough to (reasonably) infer the 'cost per byte' for long buffers. I think I'd time a simple byte copy loop for comparison purposes. (You might need a barrier() in the loop to stop gcc changing it.) Alignment wise, on some Intel x86 systems the only makes a big difference to 'rep movsb' is 32byte aligning the destination buffer. I don't remember what I got on the zen-5. 'rep movsb' on my zen-5 has a couple of oddities. - There is a small penalty is the destination starts in the last cache line of a page. - If (dest - src) % 4096 is between 1 and 63 everything is very much slower. You might want to explicitly include something for the latter. (I found it getting strange timings for misaligned copies.) Otherwise I got: length clocks 0 7 1..3f 5 40 4 41..7f 5 80..1ff 39 (except 16c with is 4 clocks faster!) 200 38 201..23f 40 240 38 241..27f 41 280 39 The pattern then continues much the same, increasing by 1 clock every 64 bytes with the multiple of 64 being a bit cheaper. Those timings subtract off a 'test overhead' that may include some of the setup time for 'rep movsb'. (I need to do them again using data dependencies instead of lfence.) David