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 1AFA7C02188 for ; Tue, 28 Jan 2025 00:50:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6787D2801EA; Mon, 27 Jan 2025 19:50:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 627D42801E4; Mon, 27 Jan 2025 19:50:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4EF062801EA; Mon, 27 Jan 2025 19:50:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2FAD02801E4 for ; Mon, 27 Jan 2025 19:50:01 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AB60F1609DC for ; Tue, 28 Jan 2025 00:50:00 +0000 (UTC) X-FDA: 83055028560.19.50A4934 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) by imf17.hostedemail.com (Postfix) with ESMTP id C99E04000C for ; Tue, 28 Jan 2025 00:49:58 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fBtaD+NG; spf=pass (imf17.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738025399; 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=3+M2viXR3QWyg4+/xPoeU8KN8F4xQf41rmON2IdtU7M=; b=CFux8xod4MYG/+LCxqc/JqHFltUwCfwj+vJ+kupVUBZd+r0EQTRMle9fvBgWE1tlirbTJ5 qQZtOE4i5wK/UtW4xT29ZunNVFMBuyriKMH5+MSKsiwB/lx4X7W4wt3MXXOSaJnxgnzOVp pvLR1F/OROIJFdW76pCERM1arbTeqNE= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fBtaD+NG; spf=pass (imf17.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738025399; a=rsa-sha256; cv=none; b=pDm9IRVDscO+wBO3urKcD1gYGQ20+NfdfIlNBypxj7sBX7UWXOztPn9aCw3jDuhmUtGdyd 42GtU2waUmZ5RnyYLT/+9mCcfXblp/5zrHvPAwKtl7FKpcpd6de2roXWWR5tg3cr5YKn64 GnmfvFhMW8Q4hMawfnYW29O4cCipA/U= Date: Tue, 28 Jan 2025 00:49:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1738025396; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3+M2viXR3QWyg4+/xPoeU8KN8F4xQf41rmON2IdtU7M=; b=fBtaD+NG/2sfPKu5QsEmlCxIvGJnruwjyDLgUiuBuUzVHCau7y1EFbxwnsyYGjbOT5ROiI TiSkh0BAR7DLg5EELOb5TuIciHEBH8LfsrdrP0UQ0TDzfCWAqIDB83j5OmDN6ysCT7xKvJ 7i7msW2EdyBOq6Sr9PESq2pODTJ6kIA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Sergey Senozhatsky Cc: Andrew Morton , Minchan Kim , Johannes Weiner , Nhat Pham , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 5/6] zsmalloc: introduce handle mapping API Message-ID: References: <20250127080254.1302026-1-senozhatsky@chromium.org> <20250127080254.1302026-6-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: C99E04000C X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ori3zchq49ydrtgcn38sd6qesu94oxra X-HE-Tag: 1738025398-83313 X-HE-Meta: U2FsdGVkX1+EOebe5VdyCk2gAfSHlvxMUiOmIg4Cfn3Ku802i5E2q0ieHMcW/0oJxTZm7NCaeZNGnZNSUMb1PvdnM2AJ6sg4FrqZNsdtPnaDBvYljO96Z3HXq+0Fz1HPRGnoQBzzktb242T8k/ZSIVzIe7VVahsFqbMsWRlK8hkHM0DpvCrbDGIhNi8GA7EmBUrQbVddqEGSpJutpKfvi/os5inlk4z7xuDxxLDi67ZhLdmWmuQf9vpChVXL+benYUMO24YFx4WkQkdRf0sCmuFxJvyvU6MoFQ/RZBC/F8Ig/LJ1nZSVU9xCcl/ga7+ZAA+zuaJ2AUzwxL2+2xVNrsbs9BM0qv9LM9uebHDyttnC64q4GMJ0j0ADcthnSOzcuFhy6D00S2gCmM8BUlEMAtKJB0KYJ8Gxxx7Gj6hvB1Oa1D4+U8M+p8MB4Ka2/3mcmy3TZWN316hTO9m7UKJhDk099w0i26aPv9A6vGlRQIVVtxa9vwdgNZueXbLzeS6YkEYWec9P0taezRcNDWcL2y8eKBvAKWSK9c5T6GCj8reClw2bqLC41d7q2Desx9WJzk4zKT0ynXWGIEAgqxw+PatqOsZ8RYE9W5SC46Fx7nKGxDA4cr31BOvKoIz3fgsKOSRsvrvR0dn5TCLfAZO/sEf7wJ4lPTdy+oqQV8VrXG9JV7/HaCu8o6Ux85kbHrggPfF8aDRjpGapl4TQUsDxywuBkZv/drrCo/BWVN/lTbLHOp2dKRuNW2vY2omB86T6CuR6cGt9rDFZ9d3pOR8pI7jD5ngTRpX2s9araIE8RgpE4/CHSo9Ct86aUYxsU5ZqxQPfEg53hDebXIXXhIlj3+63lv/LOrgqeDWv35eWfaq6ZHe8Fh2I8/fys1nPCnyhOJJV06YT4/qvgjmgkkbbP05yhXY4Vu72wUwrYLle2PGWosSyi1Ih0FVSUHeOgLeLhfEJ2YV48jJ2vu0fPSx qqj6OeQV CFktt7q9GuoQySRoQW18XzGM6Wg0b6o/hVKyXGjMWJJnWazCFvdeA1un93GvkIoWoZ8MzskrFF/BMtffEwWvL7cedF1XrhsleUJVHRVaH/av9jT2yzP0Daeva8F9ULqV1DgTFRr69ggxbqs3QLM/sgg/S2YDjuSCNURNZQVIDFQGQhBd2+LAF6QfVtdajuR8/4izMp1/gGb2H4NfxrVxBFhgUXQ== 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 Tue, Jan 28, 2025 at 09:37:20AM +0900, Sergey Senozhatsky wrote: > On (25/01/27 21:26), Yosry Ahmed wrote: > > On Mon, Jan 27, 2025 at 04:59:30PM +0900, Sergey Senozhatsky wrote: > > > Introduce new API to map/unmap zsmalloc handle/object. The key > > > difference is that this API does not impose atomicity restrictions > > > on its users, unlike zs_map_object() which returns with page-faults > > > and preemption disabled > > > > I think that's not entirely accurate, see below. > > Preemption is disabled via zspage-s rwlock_t - zs_map_object() returns > with it being locked and it's being unlocked in zs_unmap_object(). Then > the function disables pagefaults and per-CPU local lock (protects per-CPU > vm-area) additionally disables preemption. Right, I meant it does not always disable page faults. > > > [..] > > > @@ -1309,12 +1297,14 @@ void *zs_map_object(struct zs_pool *pool, unsigned long handle, > > > goto out; > > > } > > > > > > - /* this object spans two pages */ > > > - zpdescs[0] = zpdesc; > > > - zpdescs[1] = get_next_zpdesc(zpdesc); > > > - BUG_ON(!zpdescs[1]); > > > + ret = area->vm_buf; > > > + /* disable page faults to match kmap_local_page() return conditions */ > > > + pagefault_disable(); > > > > Is this accurate/necessary? I am looking at kmap_local_page() and I > > don't see it. Maybe that's remnant from the old code using > > kmap_atomic()? > > No, this does not look accuare nor neccesary to me. I asume that's from > a very long time ago, but regardless of that I don't really understand > why that API wants to resemblwe kmap_atomic() (I think that was the > intention). This interface if expected to be gone so I didn't want > to dig into it and fix it. My assumption has been that back when we were using kmap_atomic(), which disables page faults, we wanted to make this API's behavior consistent for users where or not we called kmap_atomic() -- so this makes sure it always disables page faults. Now that we switched to kmap_local_page(), which doesn't disable page faults, this was left behind, ulitmately making the interface inconsistent and contradicting the purpose of its existence. This is 100% speculation on my end :) Anyway, if this function will be removed soon then it's not worth revisiting it now.