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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B89B7C2BBCA for ; Tue, 25 Jun 2024 17:22:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 291C36B0085; Tue, 25 Jun 2024 13:22:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 241846B0095; Tue, 25 Jun 2024 13:22:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0ED626B0096; Tue, 25 Jun 2024 13:22:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E42756B0085 for ; Tue, 25 Jun 2024 13:22:32 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7F4B512042B for ; Tue, 25 Jun 2024 17:22:32 +0000 (UTC) X-FDA: 82270080144.10.E240CFF Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) by imf01.hostedemail.com (Postfix) with ESMTP id 8E9B84000A for ; Tue, 25 Jun 2024 17:22:30 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lI+79VIR; spf=pass (imf01.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.210.49 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719336135; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=iR9SeV4pxy+WU0xDeL//qKWcrGtBQcHjBOf0EE9S0DY=; b=Bk7WFoWwLRdELdigl3ETnSfRDvQGAXcp5GUVEUYxD/isvINLGCGWZ6ej7SEGmNRoI2FWft oS0OdDXQsA5Qujb4Bjfm/rhN3xZma6jzbIwD06eGhPFp3mzaEbV0wx2Djm3l99Ir4kqntG 7mrHuvzMYB/33o8L5S5wspulwPLTcDM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719336135; a=rsa-sha256; cv=none; b=Hiy+Bp+SYaCK5ht60aecO9NcWjXVNeqvzi9Ou5AoJ+tJ8jPvgsSyzCWwGGoi3qNVI8gBIK mGUCl3K8zCT4dwynBlVrEG1cqWfqaCigeaRhT3t524fgtRX8ETlYH9KyDCHjlH80G2ML7v onjcmkEUWNz+41YvNaH7wLSsQGdgAZo= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lI+79VIR; spf=pass (imf01.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.210.49 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-6fd3d9f572fso2781247a34.0 for ; Tue, 25 Jun 2024 10:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719336149; x=1719940949; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iR9SeV4pxy+WU0xDeL//qKWcrGtBQcHjBOf0EE9S0DY=; b=lI+79VIR4Hs3TIVnzwfNPJxLo1dzHijqr0zHUNua4HSbRcxpk4MWEf2eLm+WXn0nOD hfv87t+ZUg+Aru/IfEfeFWZEWX+KuObeBYo+TNktp3dSCpeMxFjE7Mi8oorfK1B4FI66 ObjUSiWiIJ2zZzKmj5DHzwVLmKLkfLUItQfWsEEP1n1j6vZzBS1PnvML9hCIFG8AhAtQ /Neh7Z+L21woxr2nfGnCsg+6p8E0muicaIZ5zr5oo92ZM96y1CYrfTQfmxNNvnrfnVdG pblnVRGaj5qgTpt9OLWDcLe4VL0JLgFVG9xSYhmgOhjUHdLvV9u6J4DqHtXL+7ogK/9M 4pFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719336149; x=1719940949; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iR9SeV4pxy+WU0xDeL//qKWcrGtBQcHjBOf0EE9S0DY=; b=hB1zNPQD0Dcu3Cv18OGjQY4tE/Rjmc1Qha86NTeEsfW6SjfwHB+Ex0Oy9b1zzffnLY rqQ4Rpq3/7EJ35cRbh2s6AoaqME0u9pQn2znV4A9Nv/hjj+PtXnBOLYrSMZRZ1tSM6GW KIQnu1wjFiraABAha5SXvZYwVpUzZvDrl1y8cmkDiU6PcnbKMCPUb4s1eODV45n/Hpvj EH/w3s856WTuNFAT31/W72bwdVaD69sVqKZ9g6ZNWXx2e8JCPYjo3FyYTjpnHneUoX5T KMhXTgAy8G41KQeBbVt0nZqiPAh1KUcP7lOjEI1ieApYXM56o6a7qu1r2rrZhYIhavCe 4egA== X-Forwarded-Encrypted: i=1; AJvYcCWH6cnHIesiv/IOWYCb7XIsAiidOKs2rsHFtzd1S2o32iZBirN6slM5cesd+tV1Uof8xWtNGHxm4u5lHuDc5ECA+Oc= X-Gm-Message-State: AOJu0YxVekQJDWPClvRRj5MhCpPJnB/K6ElPiGioU3U5EK3gwOCLLmA4 5FjvZ2ImG3MKhdbkMze8XVNZs3LaKGDMjo753jNqsWPOtpYxBUVNp6AKmS4+lDi9XXQOOzRXA/x gTL9s3bEmn+mz/WZvkc6aQce+Pig= X-Google-Smtp-Source: AGHT+IGIX/OWWQ3YYXQRyGoc37njyeD/BNo5C5vYns2lrJ0wN7DO8N9M9ykspRsi7Y/SeC9w7j3kUtqSDrGCWEK1sac= X-Received: by 2002:a05:6830:310f:b0:6f9:710e:65a1 with SMTP id 46e09a7af769-700af9b9389mr11300226a34.28.1719336149343; Tue, 25 Jun 2024 10:22:29 -0700 (PDT) MIME-Version: 1.0 References: <20240621054658.1220796-1-alexs@kernel.org> <2e9ce344-e25f-41e0-8ca4-b6d80e095735@gmail.com> In-Reply-To: From: Nhat Pham Date: Tue, 25 Jun 2024 10:22:18 -0700 Message-ID: Subject: Re: [PATCH 00/15] add zpdesc memory descriptor for zswap.zpool To: Yosry Ahmed Cc: Alex Shi , alexs@kernel.org, Vitaly Wool , Miaohe Lin , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, minchan@kernel.org, willy@infradead.org, senozhatsky@chromium.org, david@redhat.com, 42.hyeyoo@gmail.com, Shakeel Butt , Johannes Weiner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: jxb7caoc14r9kbcto1owwh7jskd3hhc5 X-Rspamd-Queue-Id: 8E9B84000A X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1719336150-57120 X-HE-Meta: U2FsdGVkX19hlp/nmFgKMdytlwv0wbR2X6DhTdrg6FLrqnUe/XxdGKib1mF8V/yCMD01tFm1Lv7Y9CW/HWAl1Lb+7CPrO8woDBOTA05N5qyAgMLmDEVpuY9VVMIfVqexZ33RWVwg5zDWqJ1tw7HbaEfFwGw5XD5LPrDdrGOOPWiOtv6za0ssG3/ibcpwgCBePxU6r2OMtoFcr5yE1/r1b1qMuFQHbbWZUcI1rl8b5q8A4q42uqIf7GM0T0JJGBXyiiBTguswQU0RwkBRoPbpZ+SaW2pIsbKweP0MYkuFaybgJBeEmusFBnWbVLi7BVRQDktsKWatm8eTWoDycGNFJwD1ZQrDwGDgO68XO7hHmU+6YOpoT5nJYGMEIEqCAs4EAvlFxWFjC8txw1cY7FO1Nj1Fj9VkwloWk7csw300oaEArOoHj6sArUDMe1lRnMkiSUvAcV5YOFfZ2XovgaC0i6l0PkBwcyIQ4Vvwe5OPXrNIwKK3WN37LlJWqA9avp9z5gIeVkzXvZ28wh1izQbNGm/n8KSwElXKt2cK5Fe08TqsPxQ8LfhKa1vkhpJAHEjmODZKcZm9LRrewCIJC4nmMr9c6zy2deOX1a6OAHJyrZx+7HkwYFJBj752KpCqGzd8c55ncGeOJ+dmmRg+ISFYXe9S2t/jR+URhwDbvCUBllP+8tQBnEodj+lXP/2TR3jYNamO8nWRlUXSR0gpBhlJ/SpcPxquh/aMcVr1XusqhcSrJyq0Vr94MfymeS+PrW9ojuSK7z5SlLBHebAme1TDgrUpvoGBCv6SmnWU3qN4rPU6+kAo+hx/Xd3sZItUdvAVZLjSCcoXeomHJQGF6L4AKeDt//aHk5AsusVfZWBoG8r4AYaaOBwfsPmtqnZWZ7USxc/URQxTjEr80wZmgcO/xy/Npwxld3iaaOUIRY8IjnMZj64kZ4sEdFgO+LzjpWOCr7zxbju2Y1Ct+hjoc1M ZbyoJ+JR 1iQJxuER630RlZ2j7d63iH4v2LJTTrMUcccYCE8V1kEEyN6M39e1IzcZZ9BdCVQS+H6GnWHB4r6dZvWc0cNsAUQNX/xBQAlv0WxJiSs2Q85rMTqAAa/BPk4rHVCTwxQy8fTgfrifh0iQ2Ce+zvl7IPGyPyac+ujElVAidfEowNRYSgz143KKLQAZqUmzyBTyPN2W+pcuYfKXqiGEIMnBBokFxSM/KfTn+hIilzrkscaYL8NvOVKg3p/DMpmmLq70O+igoVO7p0hZs+MIpIQAX27Cbr1NgDvkyoDcM2WgVR+nKDkXWePMmfL6bS44pU6FciDZXNOwQ883M/w1GZs640TepB2tG5RCMCXWuzfxoPmhNiZwl2uX0urm+G2o6pjv/Dqiw7lkHHNCnjF89KkoS+PrVTQd6OQBUwvZi X-Bogosity: Ham, tests=bogofilter, spamicity=0.000288, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jun 25, 2024 at 3:32=E2=80=AFAM Yosry Ahmed = wrote: > > On Tue, Jun 25, 2024 at 1:11=E2=80=AFAM Alex Shi wrot= e: > > > > Thanks a lot for the info and comments! It's my stupid w/o checking the= email list before work on it. > > Anyway don't know if z3fold would be removed, jut left this tested patc= hset here if someone need it. > > It's partially our fault for leaving z3fold knowing that it is headed > toward deprecation/removal. FWIW, I tried to remove it or mark it as > deprecated, but there was some resistance :/ > Our apologies, Alex. Thank you for your contribution regardless! Regarding zbud and z3fold, this is the second time this conversation has come up within a week or so. Chengming was trying to revert the multiple zpool changes. zsmalloc (after we re-introduce the class locks) does not seem to regress (at least based on benchmarking), but z3fold and zbud suffer. I think we are starting to pay the price of maintaining z3fold and zbud: 1. Future improvement to related subsystems now hurts z3fold. Developers/maintainers have to spend extra mental capacity to consider this, and users could potentially see worse performance if they select z3fold/zbud unknowingly. 2. Contributors are confused on where they should spend their effort on improving. Can we at least have a roadmap for deprecating these 2? Something along the line of: 1. Deprecate either zbud or z3fold. We do not really need both of them. 2. Make zsmalloc independent of MMU, somehow (IIRC, compaction was one reason right? maybe making zsmalloc compaction dependent on MMU availability?). 3. Deprecate the remaining one - zsmalloc can be used in all deployments no= w. 4. (Optional) Maybe adding another allocator for the edge cases that zsmalloc does not handle well? I'd need to see numbers to be convinced that this is the case. I think I saw somewhere that Vitaly was working on zblock - look forward to seeing this :)