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 16359C3ABBE for ; Thu, 8 May 2025 05:58:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F0E3A6B0082; Thu, 8 May 2025 01:58:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EBCB46B0085; Thu, 8 May 2025 01:58:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D85476B0088; Thu, 8 May 2025 01:58:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BABB56B0082 for ; Thu, 8 May 2025 01:58:24 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C0BB01A09B7 for ; Thu, 8 May 2025 05:58:24 +0000 (UTC) X-FDA: 83418685728.25.3976A88 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by imf14.hostedemail.com (Postfix) with ESMTP id CF6F9100003 for ; Thu, 8 May 2025 05:58:22 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=PqfsrkDY; spf=pass (imf14.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.215.176 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746683903; 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=+e5r5WoTNEt+2nCRRiXSbdXuZcVrl4MaI46ssYjydio=; b=foU87XfU74z3GR1il0V72cH3Fk5uTVTmHv23aIIZAj2tkv3x7MCZ6qPZflNhENzxXB9IrX GqVjJFfpAvWQ8Hxsvc5T+CO+ncvZnogXZpwpxarsPndajcBjoR7xnFyyokEfvnDqNmE4Pp WgIC3ZmFh9+V14egyU2/AHkfXgZq4VE= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=PqfsrkDY; spf=pass (imf14.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.215.176 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746683903; a=rsa-sha256; cv=none; b=CGv2FnyY9OygP4hnJjSyUH4JzylIE63uv+u1EXGTtAfEXYksbwzcIAt8xcxazeJ84eaEMa xLn6nq1rw8BugXlPozbBPe08x1+uSdDoQZKuf8XriFdsVdBiBIIsBYlvISkTOOIOr5rpjC eP7w18pxuQIea5IXH5WHV/zLPKS3+uA= Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-af908bb32fdso572118a12.1 for ; Wed, 07 May 2025 22:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1746683901; x=1747288701; darn=kvack.org; 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=+e5r5WoTNEt+2nCRRiXSbdXuZcVrl4MaI46ssYjydio=; b=PqfsrkDY7x1pZdxAEZFX6f+4dCqHcWIp0YFUoM3qz329YeybijF9np5JVqOLD2BDZY djCAhRGqm9kK4o0v2AQx9CMTsOUMxz8eReE4vs0gh0cH7mMDYGQlBQy1RJQhecVrW4ge fDuM2SHPwqQfMLmKwHiVu0bLqERs/dpDmOCoM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746683901; x=1747288701; 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=+e5r5WoTNEt+2nCRRiXSbdXuZcVrl4MaI46ssYjydio=; b=UPVZk8puBwDPpReT51S7Vm5RAEAPDNpNnht43rGvyNcLXrO6Z8Xr03n9gAfoYlzcp9 k1G2QL4i6VvXzs4bX8bAccFa4ne+CvGvvJCPHwANNlUm8OkNE+X74eZlHO0zwaInnkVZ RGS5d1HB3xOo6MexLcgjlmGh/5Rdt4WPBMS1PxL8TwbRmlnf9b8FBEP0Wh/I8G5Z3IKO B+GI1KofXkrdtYy0JrPZUHjJ7BV4gkz6IAFjFks4VbtaLdId9ytOFj0X/E0EtJoDNiKT zxJqdrShbhzmsqIJbniZLsCP8gDRPenttJ4wYv46IquEpuafRFNVN2Yd2csP0AmqCBgD WYTQ== X-Forwarded-Encrypted: i=1; AJvYcCW2hteVlXXjaRE4yA+J6D6O3Ozt5vnLdULzW6o05V98qSg4tY4yelXdn8i8p2P2YYayzbUobVRucg==@kvack.org X-Gm-Message-State: AOJu0YzvOyy6IpLOTv+dyhXZ+VQD0WpwrFwGVa2AnCZrtM/LTRaR8f2a riWHXlh2WT2XAG0eQnnG2a15+N3VD8Z2wvdO9F3JPQxdsWf6qaYJBM8fkxTVRA== X-Gm-Gg: ASbGncsy5Uvfv4IckIKs1woqf4qAJ2xH5I8Mi05g+2c1KcltKvEQ/994MWL8J7FAr19 sY+Y5EYLo0S/Ze8dlHAwG79HNV6CPrm8G4TbPr6xks42sjW4fofuv73Cz6jp/iTtnhnXO/HneLC NNeHjIXapF6U15SW7l0XKX06+6B9wei80GD5JIuCPBp7EXoOg4mOzH94+Y1ZTRxlLHPtVEu2J/i arAt1CC47jGJi1OarxA8c2KWMi2DcOwu4285DK/T9c0fz0ymYwgtEGT9tdIGuUDKAPYvW1vtfyx laZ6oTKGDmewQHVdMNC5lTrowwP3QwaQ9LgHjcEqqfFl X-Google-Smtp-Source: AGHT+IHc/oU3lljiV4zShx/DsL9F8EEmzVZbcTYXDGw7R5XiBo2bpyQ7wNVPTDw7uDaWETzfVwwexg== X-Received: by 2002:a05:6a20:3d95:b0:1f3:1ebc:ea4a with SMTP id adf61e73a8af0-2159a05e8f7mr3791386637.20.1746683900752; Wed, 07 May 2025 22:58:20 -0700 (PDT) Received: from google.com ([2401:fa00:8f:203:c794:38be:3be8:4c26]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b1fb3b5c199sm8907087a12.29.2025.05.07.22.58.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 May 2025 22:58:20 -0700 (PDT) Date: Thu, 8 May 2025 14:58:14 +0900 From: Sergey Senozhatsky To: Christoph Hellwig Cc: Sergey Senozhatsky , Yosry Ahmed , Vitaly Wool , linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Nhat Pham , Shakeel Butt , Johannes Weiner , Minchan Kim , Igor Belousov , Herbert Xu Subject: Re: [PATCH] mm/zblock: use vmalloc for page allocations Message-ID: References: <20250502080156.1672957-1-vitaly.wool@konsulko.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: i1fgnhcp71ee5ueghdskp8aos3sa1w67 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: CF6F9100003 X-Rspam-User: X-HE-Tag: 1746683902-856360 X-HE-Meta: U2FsdGVkX18lV4D8j/1RSGllhYwaUFDBxXJrulqiTU3ia+FHDvoLh2+pfBfopQH1VK29wWCxygwx5B0NKuFyFHrwB2zqshVUVxw1MejLzYx7TZgKkSsuC+ANx33TLdTEHABarni8VLYBy04yubMmzpSXrrQT6d6MBFgkwXiYNyb/Syl/d9vEW5v9pWhP6yU5ytYttBUtEUJDk2fF8GCMVUExqudHd+GMlhiGI5wzwE9CL4AI6qgtjNHNkz8JBItV15fWY3WN4ylK8nJEDv47fr4fo04foA94gQ7WnlEMy4VXZ3clrFl5ZDnF1370rGIxrF6LDAACtr2mvuSOFPe3Ce7giOush0cbaFvHL8QLctq4T7rAX73fh7KnKsiq1TL/hwosS6woI3AtgUP/1hUAqDsw6O3BvnRUgWU+4jEKU9NChEuDKctT4cJySyiYAshew9oFr81wjiHLJFPp5c6ZSvfvUylC0HNPQEXl/GC3woSwktcY7nX/yt5I+oM6+vOdBmLuWMDTkxUk3yRIdkNqMUCu/cLaBqWU1dCe33h2pIJyVGW5EL0wIqbG1PDTvp+ar5CBM3hMW+FQrb4jQnetgQaiVlMXl1HP53S2UsDTighayE00n0lzSEtreWjdxM4yMiIGTPZtlVXgpR6SA39iLKgWB5AfRYfOaha6agX3lgdMTnwxdx0EiUp69wiCt9qbJdjp8hbOgzrT1rDmkgxbx3jSQcF5DQxNMg6h9TtRCo10Cfod3ju6bg9n0DbTsvdr1WDNPNFhXrS7WV+iz3GLMLL/u5mwEgeXgH5ALeWVWf6ALSOfInxKT51gSedztMlk81d2BCwb2+n331dpYOospMQOOmJEBcC5b3ezA25RpSTKURb51PKTozGfFWmKQnQL5zLjYunEZYz/rZ818QVTnppW0ceR94O0xMgmxGFsVIeUxHHmA4D/FLBJO6z7Bmgk8N3S2hRrm2OPl12dq47 3jRF/GRi pwtp1W7MQuN63xLgTNeO7MCUSa54pzzB4R2DLW4HUUwGdb1ZHTekLWJGy+QEk4K7qarPyw+05RbMucUr9uNyd5Vmy2NySjuzXwJsY3PvgBBjHBf4as/4hM60WlS8NSDHj2n3M+QzJ1J+5ZKTbQtecCO3Sw3s8h0GhGFObuY/zjBA/q1IfuEte6szk+l8l/L84p8CuRYiB9P06+VNSTzO8qw1IpMyBEbDHHSv4dwGIQud2NEeoKxEMbvp32stDcEZIpEIg7Alz6xN95/Un5Lqsxs5bDoEQd28NiKrdq/QJpHL2wXao8T3k6bu5zv/r1wzK3AwJYvVs5CxCw43gnsLRJTCm+xDFgWx/6fRUY1QPbDoMf1k= 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: List-Subscribe: List-Unsubscribe: On (25/05/06 23:54), Christoph Hellwig wrote: > On Wed, May 07, 2025 at 03:08:08PM +0900, Sergey Senozhatsky wrote: > > > This sounds interesting. We might get rid of lots of memcpy() > > > in object read/write paths, and so on. I don't know if 0-order > > > chaining was the only option for zsmalloc, or just happened to > > > be the first one. > > > > I assume we might have problems with zspage release path. vfree() > > should break .swap_slot_free_notify, as far as I can see. > > .swap_slot_free_notify is called under swap-cluster spin-lock, > > so if we free the last object in the zspage we cannot immediately > > free that zspage, because vfree() might_sleep(). > > Note that swap_slot_free_notify really needs to go away in favor > of just sending a discard bio. Having special block ops for a > single user bypassing the proper block interface is not sustainable. Oh, I didn't realize that zram was the only swap_slot_free_notify user. zram already handles REQ_OP_DISCARD/REQ_OP_WRITE_ZEROES so I guess only swap-cluster needs some work. Are there any blockers/complications on the swap-cluster side?