Thread (96 messages) 96 messages, 16 authors, 2025-10-09

Re: [PATCH RFC 31/35] crypto: remove nth_page() usage within SG entry

From: David Hildenbrand <hidden>
Date: 2025-08-21 20:37:41
Also in: dri-devel, intel-gfx, io-uring, kvm, linux-arm-kernel, linux-crypto, linux-ide, linux-iommu, linux-kselftest, linux-mips, linux-mm, linux-mmc, linux-riscv, linux-s390, linux-scsi, lkml, virtualization

On 21.08.25 22:29, David Hildenbrand wrote:
On 21.08.25 22:24, Linus Torvalds wrote:
quoted
On Thu, 21 Aug 2025 at 16:08, David Hildenbrand [off-list ref] wrote:
quoted
-       page = nth_page(page, offset >> PAGE_SHIFT);
+       page += offset / PAGE_SIZE;
Please keep the " >> PAGE_SHIFT" form.
No strong opinion.

I was primarily doing it to get rid of (in other cases) the parentheses.

Like in patch #29

-	/* Assumption: contiguous pages can be accessed as "page + i" */
-	page = nth_page(sg_page(sg), (*offset >> PAGE_SHIFT));
+	page = sg_page(sg) + *offset / PAGE_SIZE;
quoted
Is "offset" unsigned? Yes it is, But I had to look at the source code
to make sure, because it wasn't locally obvious from the patch. And
I'd rather we keep a pattern that is "safe", in that it doesn't
generate strange code if the value might be a 's64' (eg loff_t) on
32-bit architectures.

Because doing a 64-bit shift on x86-32 is like three cycles. Doing a
64-bit signed division by a simple constant is something like ten
strange instructions even if the end result is only 32-bit.
I would have thought that the compiler is smart enough to optimize that?
PAGE_SIZE is a constant.
It's late, I get your point: if the compiler can't optimize if it's a 
signed value ...

-- 
Cheers

David / dhildenb
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help