From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7606922D792 for ; Mon, 16 Feb 2026 07:54:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771228443; cv=none; b=YPlDGX4EXiPP2OuXnjYO42Qhasv4WJUkFnWe0NREWKEG5RgkrVrFvKg5o0tisa8dKY5JOuczdECGuXR4Rw0n6zhsKXXIos0MKvD/3m3IzY9wk+uQ0NyJ7bgsLfwocewwPr+5QHMWDZJLN1IV8223CdK3/2ujsya7jbTq8OFNwQo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771228443; c=relaxed/simple; bh=2eVmDcVj1nsV90zWk49FkYNaIDozDhsASTUVe5HHkg4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CCHkA/zpei+wQF6V7ajxVpUaKk0jPKIOWoPxtnhPmyYLEi9un2XXbOcTMa+xGsPU4nljWaFuQgnjbzxyBrVM1nV/JthGM5IO07MIrwuw9oz/Big7tW9VHDmUuPjyb9o9u+cSA6khJs3xfCxJEHMHHlUjmBNLkejihc6/8gM2laQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lEpbQrCq; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lEpbQrCq" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2aaf59c4f7cso13115955ad.1 for ; Sun, 15 Feb 2026 23:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771228442; x=1771833242; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=I14tbVEH2syUi6Y61oy9PC2wsHETyhymJpQijnsyHLU=; b=lEpbQrCqStAEoabqIZs3cmpbcO9QjkRn4e/ISys0ML3FseyaVe7hQXv7uARRIroWSn GTO3BJC+N4Pb9KdibWMLvbilp9mO7pCuxffJbnIKfoMlJh0Xa/Doadl2y5ub7+BcKn0v bD2IiyoAFO8nsjMXxBy1R77isI0lBKILSsgDY4lDCGHqVl9lC1E0dE5fcAHyCuNqtXgS w3K4Pxm9qfY7uapSLET8C9vc1k6mRlx6h208hzFbSlYeXJF31xY7WWRPuZVOybDqMgsE ccpQT9+PhXtD2Z6fl3XOlpGcPmIvg/f2/Prr/JssngPjTInudNwCpbolwjzq2/pH0N5s +Cmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771228442; x=1771833242; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=I14tbVEH2syUi6Y61oy9PC2wsHETyhymJpQijnsyHLU=; b=Nt117IfXZDcifrpTTHg/MP61mN/P/jYsBg0+WXMKBiocX9C5a3Iy36kl2B6Dag4UX/ KIlPCLGbtRqyVZZEs/isepluUGwODut/Sl/5pcHn6dJOE8W8Cu4xQYwS7o1guXBpp/Bl pOSsQPO362WQihkJ59F7PJn3goMUiMFLfCV9TFpqy9QhaR0Du/UTbIf9SqfrGlcD5O7Y FEriktGoiaAv5UNXorZdC2TCaB3ZNLhmRCcGNUKOnXZVs2CvMF8IUpVL+x433QdDmmlx +6SSrLG+8fX3AkemOwFOAF3ocQ2PQLu5ptTGmvR6yGZFQeXJwnQR+A4uHFbHY5RfTBj0 CRRw== X-Forwarded-Encrypted: i=1; AJvYcCWldDkXdooyCRzW3f7iOSCrbSeCjoNBTCQXIbpNsla+pcxb0jMJSoTe/Kcp/XoFH6t7kfzi3uvFnBxYIUE=@vger.kernel.org X-Gm-Message-State: AOJu0YyKGhV9KB8zB9vaMH4WhLoEsSUFORVTu8ksm1T4+IVJLYt5uvWh pg7kau0LtCtPUF7+OE2F6o5hqF3Nk3pD0ksnE3oWczcFk1DUQYkRsZ3U X-Gm-Gg: AZuq6aLCwAT6qm3wyZYMFK3jyx6kE70lcexupLrSE3Bg6RkXeA3tgFE990bpLz8BqZk pFB20iZ4xb1KbK5t5KF66f/5dAFeTdhL150gCOdk8Dr6iyT6IaMZjYNOXC89mwCV27jRbw8G5kT m8FzV+5Ye3Tj57seMXdkYLfd7sNTGmf+mvmFYIS95fwhqZbZMgkgnGCQA4+3w+GqOorE4+ix/sp SaettxzUkDpJSfev3dmGvKbBa84KdAYv7tQNAu4aQ1H9RcRotXYwOskJn01GcJA9rEtL4Or418e TCpMAFlPBL/PzD96OJcZVCTQtRSKLH9/BJYkU40zbCo+VHn8CvySMWQ0Xv9+/9ar1oPs1K1dWqP a11tDwzy1979FHg2LuCaKY9iBpMSSBV95mbLnt9QwPPWsXPVrFRRJzaSoRYQRIWkmtq7u0whszb N0Snc0bLUqfuteDWud8huOHaK0GmndZEa/iLCu4+clmwCq9a0Bu7rtxCZbSELPx7bQjHA+7A== X-Received: by 2002:a17:902:f788:b0:2a5:8c1c:744f with SMTP id d9443c01a7336-2ab505a3194mr114280125ad.40.1771228441729; Sun, 15 Feb 2026 23:54:01 -0800 (PST) Received: from KASONG-MC4 ([101.32.222.185]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ad1aafb972sm58148685ad.88.2026.02.15.23.53.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Feb 2026 23:54:01 -0800 (PST) Date: Mon, 16 Feb 2026 15:53:56 +0800 From: Kairui Song To: Barry Song <21cnbao@gmail.com> Cc: kasong@tencent.com, linux-mm@kvack.org, Andrew Morton , Chris Li , Kemeng Shi , Nhat Pham , Baoquan He , Carsten Grohmann , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, "open list:SUSPEND TO RAM" , Carsten Grohmann Subject: Re: [PATCH v3 3/3] mm, swap: merge common convention and simplify allocation helper Message-ID: References: <20260216-hibernate-perf-v3-0-74e025091145@tencent.com> <20260216-hibernate-perf-v3-3-74e025091145@tencent.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Feb 16, 2026 at 03:34:54PM +0800, Barry Song wrote: > On Mon, Feb 16, 2026 at 3:00 AM Kairui Song via B4 Relay > wrote: > > > > From: Kairui Song > > > > Almost all callers of the cluster scan helper require the: lock -> check > > usefulness/emptiness check -> allocate -> unlock routine. So merge them > > into the same helper to simplify the code. > > Previously, when !cluster_is_usable(ci, order), we only called > swap_cluster_unlock(). Now we do more work in this path: > > > out: > relocate_cluster(si, ci); > swap_cluster_unlock(ci); > if (si->flags & SWP_SOLIDSTATE) { > this_cpu_write(percpu_swap_cluster.offset[order], next); > this_cpu_write(percpu_swap_cluster.si[order], si); > } else { > si->global_cluster->next[order] = next; > } > return found; > > I assume this is what you want to do as well, but can we add > some explanation here? Yes, that's fine. alloc_swap_scan_cluster is suppose to update the percpu offset cache so if the cluster is not usable, writing SWAP_ENTRY_INVALID to invalidate the cache might even be helpful for future scan. At lease not harmful, I'll add some explanation, comments. > > Also, it would be better to add a comment that > alloc_swap_scan_cluster() expects ci->lock to be held on > entry and releases ci->lock before returning. Thanks for the suggestion, I even thought about renaming the helper to indicate it will try update the percpu offset and release the lock. But didn't have a better idea to naming and we also have alloc_swap_scan_list, leave the name untouched seems more consistent. I'll just add some comment then.