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 B5B9CC43219 for ; Thu, 3 Nov 2022 15:18:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CB386B0072; Thu, 3 Nov 2022 11:18:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 37AB76B0073; Thu, 3 Nov 2022 11:18:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 242CB6B0074; Thu, 3 Nov 2022 11:18:04 -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 129DA6B0072 for ; Thu, 3 Nov 2022 11:18:04 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9D6DD1C6EAB for ; Thu, 3 Nov 2022 15:18:03 +0000 (UTC) X-FDA: 80092486446.29.BAA2F01 Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) by imf04.hostedemail.com (Postfix) with ESMTP id C519640006 for ; Thu, 3 Nov 2022 15:18:02 +0000 (UTC) Received: by mail-qv1-f41.google.com with SMTP id n18so1309279qvt.11 for ; Thu, 03 Nov 2022 08:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=1Y91EMmWkKaDNLHulFaIVLlw/0EjJtCCjHihzz5PhWk=; b=PccX6QjizeOvlnpoTObOI84VoFlp0uZB37fB7rBt93+yxAolIIErLnWuBNu4i0hxwg dPVH6YwiBblIu/66nxf0sR77eazM57ZGbKjYGBmrS4mRy3K3NaTeWNq+c0aptUG/DjDD DyqUVvJIRrE/Ag34h5nuo6Ra/NFHTK730c1F7k2HlhR1NUZWflyGwtN2ciIT1kSS5VaJ l5OyLyfUqPVv0dEaBAF4/cPhru2PuwuMxMknIKL7k+SN4uvNRVG8Po0/N2cHlC0IDxWO Dr8ZqnSY5fryvhMDwPsW/P3OPvQ+jXM5EKNUnmno5pgAElKzQx4TzFUtVa9efERk/5+J MKwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1Y91EMmWkKaDNLHulFaIVLlw/0EjJtCCjHihzz5PhWk=; b=YB6d+zESo7dyH0YiaOkGrlo0Fc2lBUuQ2i6otjd6OyhR9eiohtCZDBUW2vDGBShkCm hVgRdiO+/uAlw1JXuUJogAfdd6NsYlf5M3qugI/8+18LDsQow776kKhF+ncOiqbbSVRW uRiZb4j6JB85Tqpff/oE8fOLRAhB5NwA9wuxjKZR0TwxsYP2NCNUQcCJ6c66L+AaPZ1I BEDJQTj5RJyUFIUg9IeD5eeiI/c7pSRoovWs52Fl43ATyxixebbVkf5xPFKBeRCQ0PNd as3eCJEXc2dYWmIbZq7qpIltD0RZJc9JxtIe5HgfeU06tpCsDp4+y2YwuExqXg8Euz9z WxGA== X-Gm-Message-State: ACrzQf2J6fH58Vkyo9FEV3/v7i1TroqT7ZvlBpAiTjeGfE+ZxQ5i2SQg nCl/Rbn1YzY0vuAqtnKSlZKweg== X-Google-Smtp-Source: AMsMyM7JB/Ih4o4p/NED8dCLrDKvYU2z10bZku6KhZ0Ar6O6VgXOvhFZQiWItlhqzX+Q37kYlFpJHg== X-Received: by 2002:a05:6214:3016:b0:4bb:9e66:1100 with SMTP id ke22-20020a056214301600b004bb9e661100mr27182644qvb.23.1667488681877; Thu, 03 Nov 2022 08:18:01 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::25f1]) by smtp.gmail.com with ESMTPSA id bk14-20020a05620a1a0e00b006f3e6933bacsm881844qkb.113.2022.11.03.08.18.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Nov 2022 08:18:01 -0700 (PDT) Date: Thu, 3 Nov 2022 11:18:04 -0400 From: Johannes Weiner To: Minchan Kim Cc: Sergey Senozhatsky , Nhat Pham , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ngupta@vflare.org, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com Subject: Re: [PATCH 2/5] zsmalloc: Consolidate zs_pool's migrate_lock and size_class's locks Message-ID: References: <20221026200613.1031261-1-nphamcs@gmail.com> <20221026200613.1031261-3-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=PccX6Qji; spf=pass (imf04.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.41 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667488683; a=rsa-sha256; cv=none; b=5M0+2Y4fE40Q/5ILUEco83oBbAFq7G92/Z7wgplx4w6TVK/o/puGLHqlTcffPQTMVm9Mg4 GjOhr2zRnrp5OTetyeiN7CKdlz/R98Hg0kRlPiA3d1maeYyahcYmmImO5tqq4mxFUf9QcS kuOQHFtFkJfWig/cR1A1/WH38GEcQFk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667488683; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1Y91EMmWkKaDNLHulFaIVLlw/0EjJtCCjHihzz5PhWk=; b=OaD7tEZk5PqMQ4YmIlqJHap3I7bVjkBByAG5SZwZn1aSQ7Lv3vEIcxAE4dPybNckq+HeC2 NU9ghmNJs1MkAsLPFO/gQChBshiFDF7qDZ1NDXFljrddJlsJ7rMkmpi9uH2+UM6Y9XikzB +mQpOxve9B33OANegN9xIoZYdCM9pP8= X-Stat-Signature: etyjna8pjj7rfjrsr6oabzapbxqb1wxd X-Rspamd-Queue-Id: C519640006 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=PccX6Qji; spf=pass (imf04.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.41 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Rspamd-Server: rspam03 X-Rspam-User: X-HE-Tag: 1667488682-959505 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: On Wed, Nov 02, 2022 at 02:36:35PM -0700, Minchan Kim wrote: > On Wed, Nov 02, 2022 at 12:28:56PM +0900, Sergey Senozhatsky wrote: > > On (22/10/26 13:06), Nhat Pham wrote: > > > struct size_class { > > > - spinlock_t lock; > > > struct list_head fullness_list[NR_ZS_FULLNESS]; > > > /* > > > * Size of objects stored in this class. Must be multiple > > > @@ -247,8 +245,7 @@ struct zs_pool { > > > #ifdef CONFIG_COMPACTION > > > struct work_struct free_work; > > > #endif > > > - /* protect page/zspage migration */ > > > - rwlock_t migrate_lock; > > > + spinlock_t lock; > > > }; > > > > I'm not in love with this, to be honest. One big pool lock instead > > of 255 per-class locks doesn't look attractive, as one big pool lock > > is going to be hammered quite a lot when zram is used, e.g. as a regular > > block device with a file system and is under heavy parallel writes/reads. TBH the class always struck me as an odd scope to split the lock. Lock contention depends on how variable the compression rate is of the hottest incoming data, which is unpredictable from a user POV. My understanding is that the primary usecase for zram is swapping, and the pool lock is the same granularity as the swap locking. Regardless, we'll do some benchmarks with filesystems to understand what a reasonable tradeoff would be between overhead and complexity. Do you have a particular one in mind? (I'm thinking journaled ones are not of much interest, since their IO tends to be fairly serialized.) btrfs? > I am also worry about that LRU stuff should be part of allocator > instead of higher level. I'm sorry, but that's not a reasonable objection. These patches implement a core feature of being a zswap backend, using standard LRU and locking techniques established by the other backends. I don't disagree that it would nicer if zswap had a strong abstraction for backend pages and a generalized LRU. But that is major surgery on a codebase of over 6,500 lines. It's not a reasonable ask to change all that first before implementing a basic feature that's useful now. I get that your main interest is zram, and so this feature isn't of interest to you. But zram isn't the only user, nor is it the primary user, of zsmalloc.