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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 A533EC2D0EC for ; Fri, 10 Apr 2020 23:11:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7946C218AC for ; Fri, 10 Apr 2020 23:11:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586560305; bh=FfeNCoXmIijEfyR1pkNRajhg9ViX3TUxB3mbIz62Sms=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=zx2uAbisvc/2L9pRoE2mriXVIxMNlI+Ii5HvExkEm290CnOYw8FwB5M8Wd8H9vg/L veQG3zqJE8JbB1UzkK9BPEek2M1RXtvF9BD/0eRuuv4elcjlKRJfbNf8iz95zGknek 4C7LigvFLR4iTrpJl8R4HiIeaHdcCl9wMU/8NSuM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726676AbgDJXLm (ORCPT ); Fri, 10 Apr 2020 19:11:42 -0400 Received: from mail-pj1-f66.google.com ([209.85.216.66]:53525 "EHLO mail-pj1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726582AbgDJXLm (ORCPT ); Fri, 10 Apr 2020 19:11:42 -0400 Received: by mail-pj1-f66.google.com with SMTP id cl8so109435pjb.3; Fri, 10 Apr 2020 16:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=bQcdpto7s/yGk2w0OzvQ6UptVyKViN3oMFbbBVW84wQ=; b=q7YTOEbnyV60h/2JZUSD3yvsv3FfYyTmAHedS5dXvC6eEJqoWdAqQM8fRMbYNEb/DL TWa8f1bEPIXO2DpHtzWmZ1hQdADUheduicV44X6NhmrZnsTNDIZa9VTHkg2rqK9WXs9O CtfQg7RxKV1aU+9PajTKBmDFHloR88hUsjTCxairuAofrjSvkiIjlmrksHhAsr4eSull P/eN5aSURPoT5uOWbLvn9TO2HAsL3MlV2FT0WDF8H+ov5BHzMNCa3A04caDPl50c1Iqw Q60AlHo9v7XVZ5xht9Dtvdi6fj0cEQuu9XG4/VxucECmylB5pc3N/jO1PdzV7ryJfNk2 odzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=bQcdpto7s/yGk2w0OzvQ6UptVyKViN3oMFbbBVW84wQ=; b=jFjuvyzg8iHEn0BzyXsyOcuMX+9/ulPTf8RuLKDgxteAeIWT3kPyc6Vvt8lhhKq4EM 5H22CXcPxBL5U5vXSljQ+6okr3V4GTlyg88ZPLWhTJKh/N3uLtJOrd8fd2Fs0wXy7l2a 14XQHNKslSG003xjm4riGXvGyoboJCUOplKBF1SYU3GBhw/tUb8I53U7R1lN5hyTS6sn vx39QM2Vi4+onOHVWFq7B7QG/eeksxGzne3KkQo/CwJgwHvnXbHyBhBNDct/qrhjWOhP f2psHDCGqcCdUU4OiTqtnGEmRUzFBcvBKAn5rO63gM0c2qM52nbhrps1ZfzAwQKHnMRU DjBw== X-Gm-Message-State: AGi0PubCEw3nWKBkKxeofpAlyUv341TQbMzuDHi9gRHEhFOwnwP9ERWb 9E5LgX7ZErVLKrbyhrn2Aj0= X-Google-Smtp-Source: APiQypIEPforRWpT0WXypxL4A3ey15BGc+kDge0iIn1cftbyny3ESjfu/Br0BZMCFGD2PtWlRrOKew== X-Received: by 2002:a17:902:b409:: with SMTP id x9mr6968379plr.125.1586560301031; Fri, 10 Apr 2020 16:11:41 -0700 (PDT) Received: from google.com ([2601:647:4001:3000::50e3]) by smtp.gmail.com with ESMTPSA id 15sm2629073pfu.186.2020.04.10.16.11.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2020 16:11:39 -0700 (PDT) Date: Fri, 10 Apr 2020 16:11:36 -0700 From: Minchan Kim To: Sergey Senozhatsky Cc: 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: <20200410231136.GA101325@google.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200410023845.GA2354@jagdpanzerIV.localdomain> Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Hi Sergey, On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote: > On (20/04/09 10:08), Minchan Kim wrote: > > > > Even though I don't know how many usecase we have using zsmalloc as > > > > module(I heard only once by dumb reason), it could affect existing > > > > users. Thus, please include concrete explanation in the patch to > > > > justify when the complain occurs. > > > > > > The justification is 'we can unexport functions that have no sane reason > > > of being exported in the first place'. > > > > > > The Changelog pretty much says that. > > > > Okay, I hope there is no affected user since this patch. > > If there are someone, they need to provide sane reason why they want > > to have zsmalloc as module. > > I'm one of those who use zsmalloc as a module - mainly because I use zram > as a compressing general purpose block device, not as a swap device. > I create zram0, mkfs, mount, checkout and compile code, once done - > umount, rmmod. This reduces the number of writes to SSD. Some people use > tmpfs, but zram device(-s) can be much larger in size. That's a niche use > case and I'm not against the patch. 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. Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Minchan Kim Subject: Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc Date: Fri, 10 Apr 2020 16:11:36 -0700 Message-ID: <20200410231136.GA101325@google.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20200410023845.GA2354@jagdpanzerIV.localdomain> Sender: linux-kernel-owner@vger.kernel.org To: Sergey Senozhatsky Cc: 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 List-Id: linux-arch.vger.kernel.org Hi Sergey, On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote: > On (20/04/09 10:08), Minchan Kim wrote: > > > > Even though I don't know how many usecase we have using zsmalloc as > > > > module(I heard only once by dumb reason), it could affect existing > > > > users. Thus, please include concrete explanation in the patch to > > > > justify when the complain occurs. > > > > > > The justification is 'we can unexport functions that have no sane reason > > > of being exported in the first place'. > > > > > > The Changelog pretty much says that. > > > > Okay, I hope there is no affected user since this patch. > > If there are someone, they need to provide sane reason why they want > > to have zsmalloc as module. > > I'm one of those who use zsmalloc as a module - mainly because I use zram > as a compressing general purpose block device, not as a swap device. > I create zram0, mkfs, mount, checkout and compile code, once done - > umount, rmmod. This reduces the number of writes to SSD. Some people use > tmpfs, but zram device(-s) can be much larger in size. That's a niche use > case and I'm not against the patch. 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. Thanks. 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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 8974BC2BB86 for ; Fri, 10 Apr 2020 23:11:44 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 52472214DB for ; Fri, 10 Apr 2020 23:11:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="q7YTOEbn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 52472214DB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 288A387D57; Fri, 10 Apr 2020 23:11:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JlVtVCl3lln; Fri, 10 Apr 2020 23:11:43 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by hemlock.osuosl.org (Postfix) with ESMTP id 884D087C9C; Fri, 10 Apr 2020 23:11:43 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 70C5FC1D74; Fri, 10 Apr 2020 23:11:43 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9B237C0177 for ; Fri, 10 Apr 2020 23:11:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 97421204E5 for ; Fri, 10 Apr 2020 23:11:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szlVCtBRtPFf for ; Fri, 10 Apr 2020 23:11:41 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) by silver.osuosl.org (Postfix) with ESMTPS id 8FA37204C1 for ; Fri, 10 Apr 2020 23:11:41 +0000 (UTC) Received: by mail-pj1-f67.google.com with SMTP id b7so1308887pju.0 for ; Fri, 10 Apr 2020 16:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=bQcdpto7s/yGk2w0OzvQ6UptVyKViN3oMFbbBVW84wQ=; b=q7YTOEbnyV60h/2JZUSD3yvsv3FfYyTmAHedS5dXvC6eEJqoWdAqQM8fRMbYNEb/DL TWa8f1bEPIXO2DpHtzWmZ1hQdADUheduicV44X6NhmrZnsTNDIZa9VTHkg2rqK9WXs9O CtfQg7RxKV1aU+9PajTKBmDFHloR88hUsjTCxairuAofrjSvkiIjlmrksHhAsr4eSull P/eN5aSURPoT5uOWbLvn9TO2HAsL3MlV2FT0WDF8H+ov5BHzMNCa3A04caDPl50c1Iqw Q60AlHo9v7XVZ5xht9Dtvdi6fj0cEQuu9XG4/VxucECmylB5pc3N/jO1PdzV7ryJfNk2 odzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=bQcdpto7s/yGk2w0OzvQ6UptVyKViN3oMFbbBVW84wQ=; b=Mkd25Xp0aOmw0Cw6R8NuWCbkYz3TSpe5ZaLv/cw2a+Ducujp7aghSP2oqBK1T4G9Xe SZSLKEAYhGOHst6wBG+B/1Ya37JjzfU0ZEPgIKwdT/FYBlihceju0hCCrGCIB7J+gxY2 yKuuxc++inw9qHMhlX7T5BRdSoKg472uerSQz106FS65eOpYm2WK6H0WRpoQAyDQUJUJ jJlFq+RvDXUYMxcza7hyx/OMbYNcpgBPg09XudBEvSxavmt5P1G0KFLH9E5YKvS6uSPF d8pmUarRu8Rn9RbJeEepCqp0UGXw28ucB7/QnsTwv+gZi/vjHcvZaZrTSrxv0meqpx2q 6u7Q== X-Gm-Message-State: AGi0Pubr5lt0PlMlJOGwxpuAVxuqubeJKlF2AnLg++Aln7xDX2Zcp6J9 Y94lKYDb/A8r3RYjq6lKs5I= X-Google-Smtp-Source: APiQypIEPforRWpT0WXypxL4A3ey15BGc+kDge0iIn1cftbyny3ESjfu/Br0BZMCFGD2PtWlRrOKew== X-Received: by 2002:a17:902:b409:: with SMTP id x9mr6968379plr.125.1586560301031; Fri, 10 Apr 2020 16:11:41 -0700 (PDT) Received: from google.com ([2601:647:4001:3000::50e3]) by smtp.gmail.com with ESMTPSA id 15sm2629073pfu.186.2020.04.10.16.11.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2020 16:11:39 -0700 (PDT) Date: Fri, 10 Apr 2020 16:11:36 -0700 From: Minchan Kim To: Sergey Senozhatsky Subject: Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc Message-ID: <20200410231136.GA101325@google.com> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200410023845.GA2354@jagdpanzerIV.localdomain> Cc: linux-hyperv@vger.kernel.org, Peter Zijlstra , dri-devel@lists.freedesktop.org, linux-mm@kvack.org, "K. Y. Srinivasan" , Sumit Semwal , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Wei Liu , Stephen Hemminger , x86@kernel.org, Christoph Hellwig , David Airlie , Laura Abbott , Nitin Gupta , Daniel Vetter , Haiyang Zhang , linaro-mm-sig@lists.linaro.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Christophe Leroy , Robin Murphy , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" Hi Sergey, On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote: > On (20/04/09 10:08), Minchan Kim wrote: > > > > Even though I don't know how many usecase we have using zsmalloc as > > > > module(I heard only once by dumb reason), it could affect existing > > > > users. Thus, please include concrete explanation in the patch to > > > > justify when the complain occurs. > > > > > > The justification is 'we can unexport functions that have no sane reason > > > of being exported in the first place'. > > > > > > The Changelog pretty much says that. > > > > Okay, I hope there is no affected user since this patch. > > If there are someone, they need to provide sane reason why they want > > to have zsmalloc as module. > > I'm one of those who use zsmalloc as a module - mainly because I use zram > as a compressing general purpose block device, not as a swap device. > I create zram0, mkfs, mount, checkout and compile code, once done - > umount, rmmod. This reduces the number of writes to SSD. Some people use > tmpfs, but zram device(-s) can be much larger in size. That's a niche use > case and I'm not against the patch. 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. Thanks. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 EF1A9C2D0EC for ; Fri, 10 Apr 2020 23:13:27 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5F11A20801 for ; Fri, 10 Apr 2020 23:13:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="q7YTOEbn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5F11A20801 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 48zYj1023czDrF0 for ; Sat, 11 Apr 2020 09:13:25 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::1041; helo=mail-pj1-x1041.google.com; envelope-from=minchan.kim@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=q7YTOEbn; dkim-atps=neutral Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 48zYg60BYGzDrCJ for ; Sat, 11 Apr 2020 09:11:43 +1000 (AEST) Received: by mail-pj1-x1041.google.com with SMTP id e16so1001648pjp.1 for ; Fri, 10 Apr 2020 16:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=bQcdpto7s/yGk2w0OzvQ6UptVyKViN3oMFbbBVW84wQ=; b=q7YTOEbnyV60h/2JZUSD3yvsv3FfYyTmAHedS5dXvC6eEJqoWdAqQM8fRMbYNEb/DL TWa8f1bEPIXO2DpHtzWmZ1hQdADUheduicV44X6NhmrZnsTNDIZa9VTHkg2rqK9WXs9O CtfQg7RxKV1aU+9PajTKBmDFHloR88hUsjTCxairuAofrjSvkiIjlmrksHhAsr4eSull P/eN5aSURPoT5uOWbLvn9TO2HAsL3MlV2FT0WDF8H+ov5BHzMNCa3A04caDPl50c1Iqw Q60AlHo9v7XVZ5xht9Dtvdi6fj0cEQuu9XG4/VxucECmylB5pc3N/jO1PdzV7ryJfNk2 odzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=bQcdpto7s/yGk2w0OzvQ6UptVyKViN3oMFbbBVW84wQ=; b=WnLu3h0YOI09ujBfbctSz1xBOy05eXUo1Nvrmrmkn0qQ3Jbr5q5g4hDjLTg1ND9lMu h8fY0QAWTMt4kufkdIUR0xzA9HAMb9jiUCBdPnq2XitXUWvCxQ2f2hmcD1FBDRd11i8l z9PT1d4vzJ/bTvw7/PMaxTxu+zd8XKN5vjeH+TJoYrQOumIeMFTTdzNvOHTIMbwWsO9a zXeOt876Au2YKG2AXy9cAKWGXWqKkqypMOBl4uts0faq8ojKKHh35mQ4fUZe30vaysDN Idre1WsGGZ3ofIGQpRj73ufJeuEzYyMMuzwwpZAy2gwoVEx5bL889Y+4CQurWLcKdRA2 HOWg== X-Gm-Message-State: AGi0PuYdYGL5LZliV12ATaGq3ZrhFlTKzxy1s8P5req5bUoPAbFS0wfz +/uyY5gvfNtqk7rRVngA/lc= X-Google-Smtp-Source: APiQypIEPforRWpT0WXypxL4A3ey15BGc+kDge0iIn1cftbyny3ESjfu/Br0BZMCFGD2PtWlRrOKew== X-Received: by 2002:a17:902:b409:: with SMTP id x9mr6968379plr.125.1586560301031; Fri, 10 Apr 2020 16:11:41 -0700 (PDT) Received: from google.com ([2601:647:4001:3000::50e3]) by smtp.gmail.com with ESMTPSA id 15sm2629073pfu.186.2020.04.10.16.11.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2020 16:11:39 -0700 (PDT) Date: Fri, 10 Apr 2020 16:11:36 -0700 From: Minchan Kim To: Sergey Senozhatsky Subject: Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc Message-ID: <20200410231136.GA101325@google.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200410023845.GA2354@jagdpanzerIV.localdomain> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-hyperv@vger.kernel.org, Peter Zijlstra , dri-devel@lists.freedesktop.org, linux-mm@kvack.org, "K. Y. Srinivasan" , Sumit Semwal , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Wei Liu , Stephen Hemminger , x86@kernel.org, Christoph Hellwig , David Airlie , Laura Abbott , Nitin Gupta , Daniel Vetter , Haiyang Zhang , linaro-mm-sig@lists.linaro.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Robin Murphy , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Sakari Ailus , Andrew Morton , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Sergey, On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote: > On (20/04/09 10:08), Minchan Kim wrote: > > > > Even though I don't know how many usecase we have using zsmalloc as > > > > module(I heard only once by dumb reason), it could affect existing > > > > users. Thus, please include concrete explanation in the patch to > > > > justify when the complain occurs. > > > > > > The justification is 'we can unexport functions that have no sane reason > > > of being exported in the first place'. > > > > > > The Changelog pretty much says that. > > > > Okay, I hope there is no affected user since this patch. > > If there are someone, they need to provide sane reason why they want > > to have zsmalloc as module. > > I'm one of those who use zsmalloc as a module - mainly because I use zram > as a compressing general purpose block device, not as a swap device. > I create zram0, mkfs, mount, checkout and compile code, once done - > umount, rmmod. This reduces the number of writes to SSD. Some people use > tmpfs, but zram device(-s) can be much larger in size. That's a niche use > case and I'm not against the patch. 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. Thanks. 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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 47AD1C2D0EC for ; Fri, 10 Apr 2020 23:11:55 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1495E20801 for ; Fri, 10 Apr 2020 23:11:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="PGgVXz/r"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="q7YTOEbn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1495E20801 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Qov2sJq65iGCWChll4MbJgfKzbl4F6BgUuoH9lu6zb0=; b=PGgVXz/ri8L7I/ NfDe844Mhs4hL4ZPlNLMQJisDO3BFttR1KdwFKnQG4TyPXTeYf1f5J+zzzCf5D3p5YGyI8GabIwqh DvNjl6L2gLLaHyMUa51iMysE6I14Ytk4YmGI8mhhiYOIvI3KEg78Ahewxf/8AwP1YdUwdqH9RBTTd 0Y+3HtSPvNHao6nsTkgYvdRMD3IRZVhqJ2mrta2pb8kcVhNCALdhDpyyOL9JrdROyWFAosk1AJUfi oyY18FfDVYt2OPVVi29NXM9H2zldN/rIOdke4PZKayBU004kh2Y++xTmH0O8wqOHRQdkFVT6CwA6F h//p093MDOBDGGE+lBCw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jN2oM-0006CF-AD; Fri, 10 Apr 2020 23:11:46 +0000 Received: from mail-pl1-x643.google.com ([2607:f8b0:4864:20::643]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jN2oI-0006Bn-FJ for linux-arm-kernel@lists.infradead.org; Fri, 10 Apr 2020 23:11:43 +0000 Received: by mail-pl1-x643.google.com with SMTP id k18so1125613pll.6 for ; Fri, 10 Apr 2020 16:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=bQcdpto7s/yGk2w0OzvQ6UptVyKViN3oMFbbBVW84wQ=; b=q7YTOEbnyV60h/2JZUSD3yvsv3FfYyTmAHedS5dXvC6eEJqoWdAqQM8fRMbYNEb/DL TWa8f1bEPIXO2DpHtzWmZ1hQdADUheduicV44X6NhmrZnsTNDIZa9VTHkg2rqK9WXs9O CtfQg7RxKV1aU+9PajTKBmDFHloR88hUsjTCxairuAofrjSvkiIjlmrksHhAsr4eSull P/eN5aSURPoT5uOWbLvn9TO2HAsL3MlV2FT0WDF8H+ov5BHzMNCa3A04caDPl50c1Iqw Q60AlHo9v7XVZ5xht9Dtvdi6fj0cEQuu9XG4/VxucECmylB5pc3N/jO1PdzV7ryJfNk2 odzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=bQcdpto7s/yGk2w0OzvQ6UptVyKViN3oMFbbBVW84wQ=; b=nbEWa7rRIaaO7Xmoblyq611mP+BQOWy5T5FE7kblnZoFakCK2DGzDKdsrDexa3tMHM g4SWNMRbr5+boawU3iNxXNzYxmw4JKNJTJ8UnAPylsSVZpudlvkQbOi4WY6+TFmBoulA +qhnrIFX3ejwMLl252SkBeKRuoWpkFLOvjVnHYZsr342G7l0FiL5LmHgy3FjTxrFg6Q7 A8GS+ULOUMetXGWQoR+saovMKCcuFJ5Fk/8qMdrlazq33FkGGXd9QTMH5D3+hfg3diIw /IxQSoibpeKHzLGLkj2+TLyuZDwL2DadCEUE5kAnY22YZWahdGjqzR/fiGEEoi1Fk7qo EIpw== X-Gm-Message-State: AGi0PubfBSaKrxTaTkpZVnbR0GYXf9pOhX2UmAsy7d1GryYKJWP3bx5G 5H/XoGObkv3IpEZtd1gb9TA= X-Google-Smtp-Source: APiQypIEPforRWpT0WXypxL4A3ey15BGc+kDge0iIn1cftbyny3ESjfu/Br0BZMCFGD2PtWlRrOKew== X-Received: by 2002:a17:902:b409:: with SMTP id x9mr6968379plr.125.1586560301031; Fri, 10 Apr 2020 16:11:41 -0700 (PDT) Received: from google.com ([2601:647:4001:3000::50e3]) by smtp.gmail.com with ESMTPSA id 15sm2629073pfu.186.2020.04.10.16.11.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2020 16:11:39 -0700 (PDT) Date: Fri, 10 Apr 2020 16:11:36 -0700 From: Minchan Kim To: Sergey Senozhatsky Subject: Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc Message-ID: <20200410231136.GA101325@google.com> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200410023845.GA2354@jagdpanzerIV.localdomain> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200410_161142_534634_7BA92787 X-CRM114-Status: GOOD ( 16.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-hyperv@vger.kernel.org, Peter Zijlstra , dri-devel@lists.freedesktop.org, linux-mm@kvack.org, "K. Y. Srinivasan" , Sumit Semwal , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Wei Liu , Stephen Hemminger , x86@kernel.org, Christoph Hellwig , David Airlie , Laura Abbott , Nitin Gupta , Daniel Vetter , Haiyang Zhang , linaro-mm-sig@lists.linaro.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Christophe Leroy , Robin Murphy , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Sakari Ailus , Andrew Morton , linuxppc-dev@lists.ozlabs.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Sergey, On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote: > On (20/04/09 10:08), Minchan Kim wrote: > > > > Even though I don't know how many usecase we have using zsmalloc as > > > > module(I heard only once by dumb reason), it could affect existing > > > > users. Thus, please include concrete explanation in the patch to > > > > justify when the complain occurs. > > > > > > The justification is 'we can unexport functions that have no sane reason > > > of being exported in the first place'. > > > > > > The Changelog pretty much says that. > > > > Okay, I hope there is no affected user since this patch. > > If there are someone, they need to provide sane reason why they want > > to have zsmalloc as module. > > I'm one of those who use zsmalloc as a module - mainly because I use zram > as a compressing general purpose block device, not as a swap device. > I create zram0, mkfs, mount, checkout and compile code, once done - > umount, rmmod. This reduces the number of writes to SSD. Some people use > tmpfs, but zram device(-s) can be much larger in size. That's a niche use > case and I'm not against the patch. 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. Thanks. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 DA7B3C2D0EC for ; Fri, 10 Apr 2020 23:11:42 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A49C720801 for ; Fri, 10 Apr 2020 23:11:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="q7YTOEbn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A49C720801 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 29DC86ED71; Fri, 10 Apr 2020 23:11:42 +0000 (UTC) Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) by gabe.freedesktop.org (Postfix) with ESMTPS id 86C196ED71 for ; Fri, 10 Apr 2020 23:11:41 +0000 (UTC) Received: by mail-pj1-x1044.google.com with SMTP id a32so1294084pje.5 for ; Fri, 10 Apr 2020 16:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=bQcdpto7s/yGk2w0OzvQ6UptVyKViN3oMFbbBVW84wQ=; b=q7YTOEbnyV60h/2JZUSD3yvsv3FfYyTmAHedS5dXvC6eEJqoWdAqQM8fRMbYNEb/DL TWa8f1bEPIXO2DpHtzWmZ1hQdADUheduicV44X6NhmrZnsTNDIZa9VTHkg2rqK9WXs9O CtfQg7RxKV1aU+9PajTKBmDFHloR88hUsjTCxairuAofrjSvkiIjlmrksHhAsr4eSull P/eN5aSURPoT5uOWbLvn9TO2HAsL3MlV2FT0WDF8H+ov5BHzMNCa3A04caDPl50c1Iqw Q60AlHo9v7XVZ5xht9Dtvdi6fj0cEQuu9XG4/VxucECmylB5pc3N/jO1PdzV7ryJfNk2 odzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=bQcdpto7s/yGk2w0OzvQ6UptVyKViN3oMFbbBVW84wQ=; b=Ofr7oA+DjvLLbakkfEON3FoLbXGrjqGDPQ9ztSG5dyxHpqYOH1JetPkV5HHsLxw0hA bqedXHj/vLN+UrRTZgL/tVX7r211yhgHjob4awGgYXa9PbtBGH2fUPYNKARsSvixFJ1V SC9I19GKLMur2c7mAAhMjoG5iDjy3xN6mK9K4p5FJodhXwfIf0maCl+YiTlWsrgRX6t4 6joykUsDhyTlgK5uKKr/1NU2nLa2qhGAH9Un1Sprb0IdS7S+AwrzM8pyaYutW++dSDVu 3ZVtae9ZCvLqIh94o9DN7hVcQyCuNHrlEM8qUhQuMxzdV+aPYQlRIbIQzdmvxiduyAHl 95JA== X-Gm-Message-State: AGi0PuZhle5+7YcAbt42INeCs2BUs43F6CJGTlicr15cFV7q5wew0/Md wfUIPGW1yi2C3/LGzQLlVdk= X-Google-Smtp-Source: APiQypIEPforRWpT0WXypxL4A3ey15BGc+kDge0iIn1cftbyny3ESjfu/Br0BZMCFGD2PtWlRrOKew== X-Received: by 2002:a17:902:b409:: with SMTP id x9mr6968379plr.125.1586560301031; Fri, 10 Apr 2020 16:11:41 -0700 (PDT) Received: from google.com ([2601:647:4001:3000::50e3]) by smtp.gmail.com with ESMTPSA id 15sm2629073pfu.186.2020.04.10.16.11.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2020 16:11:39 -0700 (PDT) Date: Fri, 10 Apr 2020 16:11:36 -0700 From: Minchan Kim To: Sergey Senozhatsky Subject: Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc Message-ID: <20200410231136.GA101325@google.com> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200410023845.GA2354@jagdpanzerIV.localdomain> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-hyperv@vger.kernel.org, Peter Zijlstra , dri-devel@lists.freedesktop.org, linux-mm@kvack.org, "K. Y. Srinivasan" , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Wei Liu , Stephen Hemminger , x86@kernel.org, Christoph Hellwig , David Airlie , Laura Abbott , Nitin Gupta , Haiyang Zhang , linaro-mm-sig@lists.linaro.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Christophe Leroy , Robin Murphy , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Sakari Ailus , Andrew Morton , linuxppc-dev@lists.ozlabs.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Sergey, On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote: > On (20/04/09 10:08), Minchan Kim wrote: > > > > Even though I don't know how many usecase we have using zsmalloc as > > > > module(I heard only once by dumb reason), it could affect existing > > > > users. Thus, please include concrete explanation in the patch to > > > > justify when the complain occurs. > > > > > > The justification is 'we can unexport functions that have no sane reason > > > of being exported in the first place'. > > > > > > The Changelog pretty much says that. > > > > Okay, I hope there is no affected user since this patch. > > If there are someone, they need to provide sane reason why they want > > to have zsmalloc as module. > > I'm one of those who use zsmalloc as a module - mainly because I use zram > as a compressing general purpose block device, not as a swap device. > I create zram0, mkfs, mount, checkout and compile code, once done - > umount, rmmod. This reduces the number of writes to SSD. Some people use > tmpfs, but zram device(-s) can be much larger in size. That's a niche use > case and I'm not against the patch. 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. Thanks. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel