On 6/3/25 16:28, Christoph Hellwig wrote:
On Tue, Jun 03, 2025 at 04:18:22PM +0200, Christian König wrote:
Does it matter compared to the I/O in this case?
It unfortunately does, see the numbers on patch 3 and 4.
That's kinda weird. Why does the page table lookup tage so much time compared to normal I/O?
I have absolutely no idea. It's rather surprising for me as well.
The user seems to have a rather slow CPU paired with fast I/O, but it still looks rather fishy to me.
Additional to that allocating memory through memfd_create() is *much* slower on that box than through dma-buf-heaps (which basically just uses GFP and an array).
We have seen something similar with customers systems which we couldn't explain so far.
My question is rather if it's ok to call f_op->write_iter() and f_op->read_iter() with pages allocated by alloc_pages(), e.g. where drivers potentially ignore the page count and just re-use pages as they like?
read_iter and write_iter with ITER_BVEC just use the pages as source and destination of the I/O. They must not touch the refcounts or do anything fancy with them. Various places in the kernel rely on that.
Perfect, thanks for that info.
Regards, Christian.