[PATCH] um: implement arch_sync_kernel_mappings

[Johannes Berg]

On Tue, 2021-03-16 at 10:30 +0000, Anton Ivanov wrote:

On 16/03/2021 10:19, Johannes Berg wrote:
> On Tue, 2021-03-16 at 10:02 +0000, Anton Ivanov wrote:
> > > Want me to test it (without the kvmalloc)?
> > 
> > Yes :)
> 
> This patch doesn't seem to improve vmalloc performance at all.

Bugger...

I was looking at it from this perspective.

flush_cache_vmap is invoked out of here right after a
map_kernel_range_noflush():

https://elixir.bootlin.com/linux/latest/source/mm/vmalloc.c#L320


If I understand the invocation correctly your patch results in a full
flush for the mapped range each time it is mapped.

Yes, that's how I understood/planned it.


The invocation of map_kernel_range_noflush() actually has a built-in
facility for a partial flush - it is exactly arch_sync_page_mappings and
it is invoked here:
https://elixir.bootlin.com/linux/latest/source/mm/vmalloc.c#L314


Right, I saw this when you posted your patch and I looked how it would
work.

This makes the flush dependent on the level of modification - to be
functionally equivalent to your patch it is an OR of all page levels
which looked way too brutal :(

That's why I tried it using only PMD. That looks like not enough :(


Can you try tweaking the mask? Available masks are defined here:
https://elixir.bootlin.com/linux/latest/source/include/linux/pgtable.h#L1474

Ahhh.


Well, I think you'd have to go for all of them. My workload is
vmalloc'ing single pages only (for really tiny objects like 24 bytes, so
it's stupid), so really you'd only get a single PTE changed, right?

And then once you do that, it becomes equivalent to my patch (though
actually done _more_ often since there might be cases where _noflush()
is called and not flush_cache_vmap().

johannes