From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92661C2BA2B for ; Sat, 11 Apr 2020 07:20:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 49C922078E for ; Sat, 11 Apr 2020 07:20:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 49C922078E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F00288E00A0; Sat, 11 Apr 2020 03:20:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB0868E0009; Sat, 11 Apr 2020 03:20:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9ECA8E00A0; Sat, 11 Apr 2020 03:20:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0106.hostedemail.com [216.40.44.106]) by kanga.kvack.org (Postfix) with ESMTP id BDF328E0009 for ; Sat, 11 Apr 2020 03:20:56 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7B08B181AEF1D for ; Sat, 11 Apr 2020 07:20:56 +0000 (UTC) X-FDA: 76694727312.03.gun52_5f73b00fb9037 X-HE-Tag: gun52_5f73b00fb9037 X-Filterd-Recvd-Size: 3174 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Sat, 11 Apr 2020 07:20:55 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 4505168BFE; Sat, 11 Apr 2020 09:20:52 +0200 (CEST) Date: Sat, 11 Apr 2020 09:20:52 +0200 From: Christoph Hellwig To: Minchan Kim Cc: Sergey Senozhatsky , Peter Zijlstra , Christoph Hellwig , Andrew Morton , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Wei Liu , x86@kernel.org, David Airlie , Daniel Vetter , Laura Abbott , Sumit Semwal , Sakari Ailus , Nitin Gupta , Robin Murphy , Christophe Leroy , linuxppc-dev@lists.ozlabs.org, linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc Message-ID: <20200411072052.GA31242@lst.de> References: <20200408115926.1467567-1-hch@lst.de> <20200408115926.1467567-11-hch@lst.de> <20200409160826.GC247701@google.com> <20200409165030.GG20713@hirez.programming.kicks-ass.net> <20200409170813.GD247701@google.com> <20200410023845.GA2354@jagdpanzerIV.localdomain> <20200410231136.GA101325@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200410231136.GA101325@google.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Minchan, On Fri, Apr 10, 2020 at 04:11:36PM -0700, Minchan Kim wrote: > 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, 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. (unmap_kernel_range is a different story, it has a bunch of callers, and most look odd)