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 C5149C3ABBE for ; Tue, 6 May 2025 02:13:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA7E46B000A; Mon, 5 May 2025 22:13:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A58476B0082; Mon, 5 May 2025 22:13:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91EFF6B0083; Mon, 5 May 2025 22:13:35 -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 723296B000A for ; Mon, 5 May 2025 22:13:35 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 91C64CB458 for ; Tue, 6 May 2025 02:13:35 +0000 (UTC) X-FDA: 83410861590.22.850581A Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by imf12.hostedemail.com (Postfix) with ESMTP id AC6E940006 for ; Tue, 6 May 2025 02:13:33 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=VfBnfc4P; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf12.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.215.182 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746497613; 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=xMLIEqGfOzm0YYGILU4uDjHdyt5U0kB2OQhIe5Xv/tI=; b=3eI9l3Lfgp8XLg9dkuCvIobQssCfTHW1bsX56BpWFcSqfoFUHNpWqT2+m7ZWLsSklNo+6C 90PPLfAuBFq4LqrW3hkop1Pqs0g1Q049MO4YJwZMdNOJEH5+BqOWhUvUYIwfuKxXpmjt9F 06rcveat6jGWRYwlQSXHYFDOHz+3nqk= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=VfBnfc4P; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf12.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.215.182 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746497613; a=rsa-sha256; cv=none; b=vzfvwZAMW6VB8BghGKoXmtWk7H8BejNItA93f/gz0SWHMzPom7Xh+70rLXPMkkAb5E36lr KU7NKdkIw84jgl2+/RJ1EmiEQYarc3pBV9hHboGuWie3RhoXnGFZI+zM4TxJbFMkg6dg5Q +OmmqxaKoqxzLJCbQMj/x6t2UXGSD3E= Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-b1fd59851baso940160a12.0 for ; Mon, 05 May 2025 19:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1746497612; x=1747102412; 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=xMLIEqGfOzm0YYGILU4uDjHdyt5U0kB2OQhIe5Xv/tI=; b=VfBnfc4P9ePu4OrwTGM647yRW3CTl8izqXgFMkprWM//Wxph2EPbrQB0ey5JaUzqAD TYY/vfu6tG+zVMtFojdMWJLO3NwnaBBq6OQTCyy1oSpPvrd1cdodmzsJ1eSORVGIkJqO B25QQEqefDJFGD+PMnEwrwfHWX/hctYXFovSk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746497612; x=1747102412; 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=xMLIEqGfOzm0YYGILU4uDjHdyt5U0kB2OQhIe5Xv/tI=; b=oJzRLLqnFx9o/1appN587H23qaWUhG7m9HLiLJWKtExDlprlu8tdQPWFfjFnBWw88W 72EmSvpmrVisdJRV1b3cMVQnOjkws3EdbI3812meP/N5tpD09AW93YK1z5y8MGf3VK7R 8ylwZYONnUNOJzZN9bZxtsm/Ksp5RpjS/Cg/7Cdu6Gv6xGYm7a4SjA5iPUlUn51W4v8X 6fIPiMdnnriOUyIhL7iI5s92B1x/74mKuBO1pJUPYnA71Dbl9fbIvPElGY2iMOllVYjR OOC9sMhonpxMLmN6Q0lwiudFDLX41xoWWGGmeZD1duJW+iuTwd+OmKgoGkJT3dJ5DpLH 49DA== X-Forwarded-Encrypted: i=1; AJvYcCV1HCdmtRwWsizPcf7kQEoSbBC9u3F40UnCEtmnaagJWz0OOCmY+OnYJGKyQupf1dEoJhjioauWcw==@kvack.org X-Gm-Message-State: AOJu0YxMylNJmvJb9eVGDnK4hX1J3fZ9mLUKiCZeNaf2nnT2fCMgaTur 0xVWMBUg3LhrnD12YGbvQaAZLc2AKgtMWZ6vof5ZugFt1shQr9dLMMLGPprY7w== X-Gm-Gg: ASbGncuKpnlQtQYcWHNZ4PWRQYYnjsLTNGIAy52gWLd/TT37QBNoJBaZzKA1+1zkpCK kEmkA/sgKPEZ27r1XgMc5UHuT7IlwnIUiRhKLbAefZuzDjTF7T6OSb2WrofeCnXUjQeibdXQDdN bW1cm39e1iyNTJ0K09Sp7jubpqOz6lMUhdGc+d/nLSbuqhbsehY7rc2l1lbHDdWUVf8DRT0kkm0 2shqAJ7lKFXPasZQV0hwp2Rv/1yk7FzN7sMZg6b+w9tvG9iv3nv+kjLpoCPLD4BE72bL/wE7JJt MmNpXgRMONVlBg9/LGFKqQv3g1I8PjQQ0bkewSoKk4tu X-Google-Smtp-Source: AGHT+IEQVeqqIQDZUu+Q1GCjvpvnxvMpU92zElefblNq0IFwm5LHHiti0J7zMIKFuwG93HIrp+UUwA== X-Received: by 2002:a17:90b:3a05:b0:30a:255c:9d10 with SMTP id 98e67ed59e1d1-30a7c0806demr2416920a91.8.1746497612367; Mon, 05 May 2025 19:13:32 -0700 (PDT) Received: from google.com ([2401:fa00:8f:203:4dd5:88f9:86cd:18ef]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-30a3471effasm12638224a91.10.2025.05.05.19.13.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 May 2025 19:13:31 -0700 (PDT) Date: Tue, 6 May 2025 11:13:25 +0900 From: Sergey Senozhatsky To: Johannes Weiner Cc: Vitaly Wool , Igor Belousov , linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Nhat Pham , Shakeel Butt , Yosry Ahmed , Minchan Kim , Sergey Senozhatsky Subject: Re: [PATCH] mm/zblock: use vmalloc for page allocations Message-ID: References: <20250502080156.1672957-1-vitaly.wool@konsulko.se> <83CB359A-955E-48B6-B0D9-DD4F2E1146D4@konsulko.se> <20250505140812.GA30814@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250505140812.GA30814@cmpxchg.org> X-Stat-Signature: 7jrqhamneusooaucghchs98oegq4qhgt X-Rspamd-Queue-Id: AC6E940006 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1746497613-108452 X-HE-Meta: U2FsdGVkX18JDWmjcaPOTk8CePgZCAlNQMogA6bN2fc//4N31s4zYNKpR25DPjSoAgRZRsJF4HxIPV+lnySwqtEGM79LSP2tD+qqJmAOW2ArZLuwT3e8nA5EvpfQZo0QnwsdnSudWJ4CqK2/LZM3nL3mXWsSRcF/J4w5cwj1qBI6tvYqABc+cB43odyRL/9JaNgxr2v+ddbTO2rVFoPZTYaubrGM8MPWTn1RTMKHGDci2mox23rHiPlAdfjxv/v+RaiICr5ODPkwhApekZ820F9AhiO9hktC3nYF7q9K4lYBciuGaOlU0Eooa6XJUhFXyMAl+/Z1xDiY2a+fx14EN8TFBARmWOgkI6HrWcMMHaz+zq8F/j9QIkrkWzdYTIkix4di7bLaBWcdPad4xQ6vqwVp5aVqyYETmJiKlOsVTd1IxwjJzEBeWCRLAfKMgSKOu0aI2yhfzPx7+ICxkRfcXo4oTNPUpVcE6PEaesMx8Rx3yJLpG8jjrKPgGPpNuMekJdL7RniX+Mf1byZRaJvl6XZTl/gU1I7s5wuar8kAnIeWDwaEZVqgeAmZZaJGOuzq1HB3YPd7YdRnV2mq2dipzS8rXpteY/46dc6Lho01X8sv02dKIFW+WmUEUvUIRPzlVmsvctenmZuXBSRpxmPXYEDSqTcGa8sNxCbRxEMX7hrSIcg8rFrEzz7/ZDTrzN9wkE86P6Hse6Zugwzt1Vr6hZ4b3RQ2+yrsbE97LRwEif52LjoUq3bHrkJ8A2VtHACGIAG9VFtsv+7MEBAwVw+6O1njLnuQ/pR62OLHRjELotUGh2Cwfi0n5JsWkJDYekEUq7gqR402b1OkCKrCRLZ4dTuabdKJbg2iWj1pHMQe7uALhVyJfVWmRzlenJtnrGriK9DvzDy+vrb+GJe7FGkR6z8pnzyAVEm7kFyCvu7WqXNa/3MgYywvLJtvgX3MAKKedDiDGFAU2yhk7nix+Q3 R3Nkwixb +TV5nU/1IqBfSZbFcm1jLTKsUMLSOQUOO7ZN/fZmt6uBpoClPr7XM67NV18nkYMSQ9oPiCZ/fOPe7FBFkxmd0UuwBwR0Pl/CjH6P8jnVjgNObuNOrwJ9yim0s3jt6CUGYn+aUTpr2uopeOsR5djmmnSHCFBWcr6ACXSEcFqkeT9/n7LDukWeTnMxuEVaETJ8bOUoKpc6eb4IrzOxVE4Y4RD10jaQdaGCPeckZdlN555peq74tD7HM6X9et/S3LblWpVgKHPI+BTeQUXJl1TAwSaHhqfRXk7hzVtS4pfDnt/goZ8bouh9cghWERd+MyGGGyrCfINMIEDuc8isaC1mAyfA9GAYpqI3xyufE8wi+jkwvVvw= 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/05 10:08), Johannes Weiner wrote: > I've been using zsmalloc with 16k pages just fine for ~a year, > currently running it on 6.14.2-asahi. This machine sees a lot of > memory pressure, too. > > Could this be a more recent regression, maybe in the new obj_write()? This looks like a recent regression. In the old code we'd something like __zs_map_object(area, zpdescs, off, class->size) which would use class->size for all memcpy() calculations: sizes[0] = PAGE_SIZE - off; sizes[1] = size - sizes[0]; /* copy object to per-cpu buffer */ memcpy_from_page(buf, zpdesc_page(zpdescs[0]), off, sizes[0]); memcpy_from_page(buf + sizes[0], zpdesc_page(zpdescs[1]), 0, sizes[1]); So we sometimes would memcpy() more than the actual payload (object size can be smaller than class->size), which would work because compressed buffer is huge enough. In the new code we use object size, only for write() tho. read_begin()/end() still use class->size, so I think in some cases we can "unnecessarily" go into "object spans two pages, memcpy() from both pages a local copy" even if the actual object fits on one page. We may also want to pass the object size (which we know) to read_begin()/end(), this potentially can save some memcpy() calls.