Maybe a bug in VMMDLL_Scatter_PrepareInternal

[mecuryittle]

The alignment calculation formula (cb + 15) & ~0x7 unnecessarily adds 8 bytes when cb is already a multiple of 8.

Steps to Reproduce
Input: cb = 0x40 (64 bytes, already 8-byte aligned)
Expected: pMEM->cb = 0x40
Actual: pMEM->cb = 0x48 (72 bytes)

Impact
Memory waste: Wastes 8 bytes per alignment operation
May trigger unnecessary page boundary adjustments
Significant overhead when accumulated in loops

Suggested Fix
// Current:
pMEM->cb = (cb + 15) & ~0x7;

// Suggested:
pMEM->cb = (cb + 7) & ~0x7; // Standard round-up to 8-byte boundary

Additional Context
This appears to be a bug in the alignment calculation. The standard formula for rounding up to an 8-byte boundary is (cb + 7) & ~0x7. The current formula adds an extra 8 bytes even when the value is already properly aligned.

[ufrisk]

I'll look into it, I don't remember if it's mean to be like that (due to some technicality) or if it's a bug.

In reality the impact of this would be pretty much zero though unless reading a lot of 8-byte pointers at addresses ending with 0xFF8 (so that the read crosses the page). Even so if it doesn't happen all that often impact here again would be negligeable.

I'll put it up as an enhancement though and will be looking into it a bit later when I have more time.

[mecuryittle]

After I modified it to the correct 8-byte alignment, I passed the test on my 35t/75t/heino1.0/1.2, and in the complex scene of an FPS game, the performance (frames) was improved by about 3.5%. And it has passed the test of at least 6000 DMA users.

[ufrisk]

Thank you for your testing. With this I agree that it's most likely a bug and when looking at the code it's only a minor change. It should now be resolved in 5.16.9 which was just released. Thank you for reporting this issue.