On 1/31/23 8:48?AM, David Hildenbrand wrote:

On 31.01.23 16:36, Jens Axboe wrote:

quoted

Using FOLL_PIN for mapping user pages caused a performance regression of
about 2.7%. Looking at profiles, we see:

+2.71%  [kernel.vmlinux]  [k] mod_node_page_state

which wasn't there before. The node page state counters are percpu, but
with a very low threshold. On my setup, every 108th update ends up
needing to punt to two atomic_lond_add()'s, which is causing this above
regression.

As these counters are purely for debug purposes, move them under
CONFIG_DEBUG_VM rather than do them unconditionally.

Fixes: fd20d0c1852e ("block: convert bio_map_user_iov to use iov_iter_extract_pages")
Fixes: 920756a3306a ("block: Convert bio_iov_iter_get_pages to use iov_iter_extract_pages")
Link: https://lore.kernel.org/linux-block/f57ee72f-38e9-6afa-182f-2794638eadcb@kernel.dk/ (local)
Signed-off-by: Jens Axboe <axboe@kernel.dk>

---

I added fixes tags, even though it's not a strict fix for this commits.
But it does fix a performance regression introduced by those commits.
It's a useful hint for backporting.

I'd just mention them in the commit log instead, but I don't
particularly care here as long as the commit ID's are stable.

Sure, I can move that bit into the commit message.

If still possible, I'd include this as a preparational change for
these commits instead. Anyhow

That would be preferable in general, but I don't think it's worth
rebasing the series just for that.

Acked-by: David Hildenbrand <redacted>

Thanks! Will add in conjunction with updating the commit message.

-- 
Jens Axboe