From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-185.mta1.migadu.com (out-185.mta1.migadu.com [95.215.58.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 834DF1DE3C8 for ; Tue, 28 Jan 2025 17:21:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.185 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738084905; cv=none; b=FP5iKJ11ISP0JPZK8zJayjTdq34rmk6Kjmjtf0wa6mzEwU7UCwhVNRx9Nt113WwyLHTGny2CIRnKb6/eon9EMbt+dBTM+LINoQXzZXsUxDnT6ckPr6mfe9BQEghIa1Xb6nGo+ahM1SgnFPi6Hm7DJ0GyYP0+16lwUcN6AIzqkys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738084905; c=relaxed/simple; bh=j/RjWF4S3HebdS4/QQPzvTsUmpu7FLdwIMChfBSzZZo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=g0lZrHY8co8CEblHRWvyaCIITcdoHzWu4BiyO/Q1bq00xMoTPtmjmleErRPKLjSfNw3BKZty3K0hTkmaDoLajbpXCilCv0sIHTObK4fm3UAMVAs33tNq144ebYDlRrYiXNiunhFbKmWk+OXt8yYbuxD9kguv+thxKbVB9jqmty0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=l/r2V9pw; arc=none smtp.client-ip=95.215.58.185 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="l/r2V9pw" 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT 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.