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 09D49C02190 for ; Tue, 28 Jan 2025 17:21:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D21A228023C; Tue, 28 Jan 2025 12:21:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CD03C280222; Tue, 28 Jan 2025 12:21:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1104280241; Tue, 28 Jan 2025 12:21:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6F00528023C for ; Tue, 28 Jan 2025 12:21:45 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1FB341402CD for ; Tue, 28 Jan 2025 17:21:45 +0000 (UTC) X-FDA: 83057527770.04.7C4E2EC Received: from out-172.mta1.migadu.com (out-172.mta1.migadu.com [95.215.58.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 309EC40008 for ; Tue, 28 Jan 2025 17:21:42 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="l/r2V9pw"; spf=pass (imf17.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.172 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=1738084903; 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=LAvm42ueExbHeHYF+xEwBmh/hs6tf8r4Bu5dS995qFI=; b=Rcx3GvFF4UkdxpGtU8Y1kCj6pcIt+I4fdVnUSFpckm6Cy4YiGUt/MH5TlQeciTvE3fF6rx EdIB/MnS4zCvYAuKGV6Dnd4+6VOjEoETUYkjn7uSHhQpqPt3r+KfdWFkopGcCDnvH9P1v/ S1TQXZGNSURftEAoT0kPpLSacLzu13M= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="l/r2V9pw"; spf=pass (imf17.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.172 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=1738084903; a=rsa-sha256; cv=none; b=mudYJLnl+GC72wi9lz8dK7PredcMDlODsDYoLsh6HAKgBGxS2a6BiQOZkokNFhtNbMTuBs lXtRQPHrkP7K6D0lz727aS0P3i2giBkWQpqYn9rr/KYCNIogA6yiUPzpCoyKKnieG93CVy fJWONVnFeQgFKI+9RVBAvaoCqIvKmSA= Date: Tue, 28 Jan 2025 17:21:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1738084901; 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=LAvm42ueExbHeHYF+xEwBmh/hs6tf8r4Bu5dS995qFI=; b=l/r2V9pwhSYyc7JSOnikC3MjVIeZYvBjTbulzk7IJ2XUvB+38JfeL0rvzLfAlHLQpyJi6w mQSjgz5jZD4s5Nuh6aYlmbtZKjleQM8wyBqIPgepEkmlw6SFbZMOS6RbacQ01W1X9eNpLG PLxBOcZ3T/TsKN0tdZjoi6qLsVtzhFs= 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-Server: rspam07 X-Rspamd-Queue-Id: 309EC40008 X-Stat-Signature: p5pgk6tmdqui4hmye3pphysubjbpnpr1 X-Rspam-User: X-HE-Tag: 1738084902-709122 X-HE-Meta: U2FsdGVkX1+Flr0A9RVchreOsGv8EEf0cHxiXuB77bQCNZxhWnHCvGKXMXQs80ON7xolZOTbczJ2d6mUawHDHttJnGI27jQV9T8cYCgGeJu7BckqkdDIdzJM6vFAKIPhM2iIw7FgtCxuEPWvJutGzfDoA75BKI/5fBselyKkgqFGqmHte6vHPWXKxUWFsah32BYjA5RtxZJr7mheHUOVgLnxQv8tHfnbIeLobIBnC/+5rqv/cPX2fd6UQVe6u/g0eZXkjQmnwx82k9yYE7taoLbBMVVgyTdrfWmO1NeTiAw/wZghuWNMuedU34oY7dZ9ZmwfpHrCr/SD5FCwtoN3/2oHZwGKNumudfKFBj8PKF2tMBx6T7wjWEZGfMb1Q9FtuxqnDY5SfdlBJofxIUtoXpF1wciIk7NAQC0d7oqTnQEpm5yEc4ArpX6rXq7GXxgSDkg9Kv+CCBZg5TjTCUkskWJP6y1yrpMIBlgGfCPPr6gkHj0q9lwYFDU3jvEIvlAba2FZ4Y2CIVytZEo3LDJKW6usBA06wRjHjEIoTuSn1VnXnRoBCvzCJmPQytvNjLFJnkVrZLXH//KhkwkPUTwlMqL4QSgJTmDtRcaki0mNamKFmeZI6h5e1yms0z9En1w7CBN+TNo5iBvydeFOrBY583x059SpiCtc7eACh3QGf+GNTLcPPgdEEVTLsu2vtB9G4k8LlB8WImAStmzfXAIvnEVwsCr16xCuTFrfc3vDc2toP/2G/xKsNUcePegqQveerfPrVLo0vKcsAhLnnPlWi3TElcNTk9GMtmLNhT02IcR7goRlefyCnuGuMiVg1P24slGPzfMAvnxPPFAWxlSaTq3XYzJDplx2paqLPWfubRvar0kNznczi8Kb6SMcgBhNxcWc3vQYmk3d5X4fxAG6one5vVwlzeeaCj0UXCwNdPwwiIFb+GKIRJ/aLC0JjM+kEz0+rA7YPrEXyUUEpTW NLt1QgPz UnXDLKlL85TWdsNfJmV9nl4uitwZFwkHFK3V1DQi9esPpX+MWbKzsXUpd1p07zQcNoj9jWN2YJRapocBFIWUwvHNRmGzA7gIe2lJbPZZxStRbJs21E/gUKEZ1Spx98VaP6AmBmNq8+gbWxQO+CB08CahQ7lweQE9SWd8MIMTvkYLjUsCuoQzikoPnf4p8KAvv51txkZpPDpNJqCQCwJ7digQe4w== 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 06:38:35PM +0900, Sergey Senozhatsky wrote: > On (25/01/28 14:29), Sergey Senozhatsky wrote: > > Maybe copy-in is just an okay thing to do. Let me try to measure. > > Naaah, not really okay. On our memory-pressure test (4GB device, 4 > CPUs) that kmap_local thingy appears to save approx 6GB of memcpy(). > > CPY stats: 734954 1102903168 4926116 6566654656 > > There were 734954 cases when we memcpy() [object spans two pages] with > accumulated size of 1102903168 bytes, and 4926116 cases when we took > a shortcut via kmap_local and avoided memcpy(), with accumulated size > of 6566654656 bytes. > > In both cases I counted only RO direction for map, and WO direction > for unmap. Yeah seems like the optimization is effective, at least on that workload, unless the memcpy() is cheap and avoiding it is not buying as much (do you know if that's the case?). Anyway, we can keep the optimization and zswap could start making use of it if zsmalloc becomes preemtible, so that's still a win.