Thread (71 messages) 71 messages, 20 authors, 2020-04-16

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

From: Minchan Kim <minchan@kernel.org>
Date: 2020-04-16 20:37:43
Also in: bpf, dri-devel, linux-arch, linux-arm-kernel, linux-hyperv, linux-iommu, linux-mm, linux-s390, lkml

Hi Christoph,


Sorry for the late.

On Sat, Apr 11, 2020 at 09:20:52AM +0200, Christoph Hellwig wrote:
Hi Minchan,

On Fri, Apr 10, 2020 at 04:11:36PM -0700, Minchan Kim wrote:
quoted
It doesn't mean we couldn't use zsmalloc as module any longer. It means
we couldn't use zsmalloc as module with pgtable mapping whcih was little
bit faster on microbenchmark in some architecutre(However, I usually temped
to remove it since it had several problems). However, we could still use
zsmalloc as module as copy way instead of pgtable mapping. Thus, if someone
really want to rollback the feature, they should provide reasonable reason
why it doesn't work for them. "A little fast" wouldn't be enough to exports
deep internal to the module.
do you have any data how much faster it is on arm (and does that include
arm64 as well)?  Besides the exports which were my prime concern,
https://github.com/sjenning/zsmapbench

I need to recall the memory. IIRC, it was almost 30% faster at that time
in ARM so was not trivial at that time. However, it was story from
several years ago.
zsmalloc with pgtable mappings also is the only user of map_kernel_range
outside of vmalloc.c, if it really is another code base for tiny
improvements we could mark map_kernel_range or in fact remove it entirely
and open code it in the remaining callers.
I alsh have temped to remove it. Let me have time to revist it in this
chance.

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