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 32258C5475B for ; Fri, 1 Mar 2024 16:31:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6A636B007D; Fri, 1 Mar 2024 11:31:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B1AA36B007E; Fri, 1 Mar 2024 11:31:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BB5D6B0080; Fri, 1 Mar 2024 11:31:25 -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 8DE0E6B007D for ; Fri, 1 Mar 2024 11:31:25 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 15D3D40DEB for ; Fri, 1 Mar 2024 16:31:25 +0000 (UTC) X-FDA: 81849010530.26.17DB3ED Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf25.hostedemail.com (Postfix) with ESMTP id 9BD49A0021 for ; Fri, 1 Mar 2024 16:31:22 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="OBrnq3u/"; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709310683; 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=6HJyOrbro+KIiOc29k/CBAdcOESXYJoi3ToEEVFHbH0=; b=ABZGwOBQaC1zx5kYSSqJDmuc8zSDyVUAlpT23h+3sLyZ5xpLEZf7j+0SCQsbwDmt8ym03p WGPgnp7wh4My5ikViozPy0W1z5DxXla2mAD8LEkp8n/dDPgraUbjH/EFoLqU9CcYRowJ5A Wx4Vp3MmS6bzpC4t1UJKmum1WBT3amE= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="OBrnq3u/"; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709310683; a=rsa-sha256; cv=none; b=21DZQNL+gGGDGNKdfUQcCVetbGwYZv3Ix3qtmu24rXUpHIF4XHH6+ZQ0qJwqvOSQyoBWNF 8HNE5ECK7luXMrRucvFr+9SCtDWk6g5HbIA2KFFn2K2BqfkPdXjxdAT7KxX6PM5yJeLOSN OpmZ6oraaGlOlVsEyqd8Sj4zMlsPlvk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=6HJyOrbro+KIiOc29k/CBAdcOESXYJoi3ToEEVFHbH0=; b=OBrnq3u/cUL6/p4MbminaXQJJH hPB9OC8nhsdBHQ0QIXcNQI8cLTXM08WxWJ+J3ivMYXdMKbffQNw9H05JryZ52YtXt+R95cZGYWA7d QcsR2RIhRvVPU/Fp2oDBBh/12JAd5O6Kw9Da0AaW1oTw/LYBJqruiOmUUMzmKIuiwv2h2GkR0oDII dnoj3dVCaoekKBCPFfWzAIEUnT5ob965mz/MKdPOa9IMOakdeMMesg75xa68bp+/DEbpVvBtvTyj/ oTEKrd0dH4i0/JbIQFNoUdVtJiojXPF/ov3wF2wMx46w/lN03olbKzXzBzkgINITohOpSSiObggI0 lYE6DL6A==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rg5my-0000000BMdT-1XZS; Fri, 01 Mar 2024 16:31:12 +0000 Date: Fri, 1 Mar 2024 16:31:12 +0000 From: Matthew Wilcox To: Ryan Roberts Cc: David Hildenbrand , Andrew Morton , Huang Ying , Gao Xiang , Yu Zhao , Yang Shi , Michal Hocko , Kefeng Wang , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v3 1/4] mm: swap: Remove CLUSTER_FLAG_HUGE from swap_cluster_info:flags Message-ID: References: <6541e29b-f25a-48b8-a553-fd8febe85e5a@redhat.com> <2934125a-f2e2-417c-a9f9-3cb1e074a44f@redhat.com> <049818ca-e656-44e4-b336-934992c16028@arm.com> <4a73b16e-9317-477a-ac23-8033004b0637@arm.com> <1195531c-d985-47e2-b7a2-8895fbb49129@redhat.com> <5ebac77a-5c61-481f-8ac1-03bc4f4e2b1d@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ebac77a-5c61-481f-8ac1-03bc4f4e2b1d@arm.com> X-Rspamd-Queue-Id: 9BD49A0021 X-Rspam-User: X-Stat-Signature: m6i96tmoj45ezcrubim5idbsa6rqou6p X-Rspamd-Server: rspam01 X-HE-Tag: 1709310682-934150 X-HE-Meta: U2FsdGVkX18q0qq6cU6sCqvW858Y4yrdGLhXhAijACeZ5/kuZQw06tORexSnl9bA4oE6DpztI3kv+QIMvVWmYQBBIm+mUx280Iy2g6a1eBVr8y61FgdT7t/6vfpB+LB/MMcNPLuBO+4mSz7tLDt0Kpdfj0ChKMPvr9Uzu6MB6suQBZeDH9bMX/PIINtiCAyLjPYxzRBAAofwqpPrUoEivBF6J6sAVEjrLyyPP1CA7T0z6vHIu3nazt2LITrR4ZwhujpVOS5ewn7YSA3TkVa8k76Cqsn5dAZx1v4rrLZhCJEyN5h5iRhAhh8BA7pENTGm/vnf8pBHlOJhrl3j4VxXDF08NfJXfFgNSc2ozT+va3CN6SmOzQevBA2yM3tRvuJzVSwOBGDo9LIko7x9r773RU4Vzo6Ic6nzgPCHFKbPFuMBSukYl1pAe6gXYqrgHOqeHHw6zNcjQ64jVXfUZbXb48aQsBkWluGGRPhgX6dT+bwE5VGAw4nE/xe4rk/qfkW7BCsYIwGmv4ajbYiIc6bQRMsKVqeyuq9J4r8i7JLkPPz/nVZ4RBHLkivb9gQExUmWSZLitFx5tc9PrNtxZXIgr5yzWmU6RdRoNRYS0pxQ6FmyVzVd3Nt/aIO2P6/4jBVq1wZKcWNFDADSEwQ7+ZMCPVY0KsW4zAqcRs3rBnABvzJm9XLbuiYwyFcSsKwzIvwq/ad73/BoY4iwe2jcu52qNOMey7tSW5VYo07yasYyq+sBs/Jwojp96ozpv3om6b20oHpIJIKFZ2ot6Qr32C777wVK4PJn91HQYNNaG2CWa/PGwNSI5FZopbP+F3Nf3wz5ITGtcIiMiKJOtwbvTahsjgyCu8RCU8jRW2m+KmzJrFwXZKaMA47JC0w2wMZ5XZbprmRMmOAtvOX2JDFtkjO4sp5g2sFmhZj9iakEHdHENeC6O+Vjrl+qQb0Uy08sv1HYU6y4EIUaJ6Jq0wIMAG7 KVcYGA2j lTnwALNefnqmyqGi5Khn4i6IEyIsQb1BxeJfg7uiolm8C0M7qZEwcAXFcNL+7eOkh3ie+/04SFN3DKJ2moHZVUnsWwxXovTTkvfmkLPeHv39GssH/+iVZ4w/O2jvjds6c+JfHxl5+b4kNCI4F8YLrMDWk49FhZxgBQWidW+JwprADAzpBolrgqiFhvw== 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 Fri, Mar 01, 2024 at 04:27:32PM +0000, Ryan Roberts wrote: > I've implemented the batching as David suggested, and I'm pretty confident it's > correct. The only problem is that during testing I can't provoke the code to > take the path. I've been pouring through the code but struggling to figure out > under what situation you would expect the swap entry passed to > free_swap_and_cache() to still have a cached folio? Does anyone have any idea? > > This is the original (unbatched) function, after my change, which caused David's > concern that we would end up calling __try_to_reclaim_swap() far too much: > > int free_swap_and_cache(swp_entry_t entry) > { > struct swap_info_struct *p; > unsigned char count; > > if (non_swap_entry(entry)) > return 1; > > p = _swap_info_get(entry); > if (p) { > count = __swap_entry_free(p, entry); > if (count == SWAP_HAS_CACHE) > __try_to_reclaim_swap(p, swp_offset(entry), > TTRS_UNMAPPED | TTRS_FULL); > } > return p != NULL; > } > > The trouble is, whenever its called, count is always 0, so > __try_to_reclaim_swap() never gets called. > > My test case is allocating 1G anon memory, then doing madvise(MADV_PAGEOUT) over > it. Then doing either a munmap() or madvise(MADV_FREE), both of which cause this > function to be called for every PTE, but count is always 0 after > __swap_entry_free() so __try_to_reclaim_swap() is never called. I've tried for > order-0 as well as PTE- and PMD-mapped 2M THP. I think you have to page it back in again, then it will have an entry in the swap cache. Maybe. I know little about anon memory ;-) If that doesn't work, perhaps use tmpfs, and use some memory pressure to force that to swap? > I'm guessing the swapcache was already reclaimed as part of MADV_PAGEOUT? I'm > using a block ram device as my backing store - I think this does synchronous IO > so perhaps if I have a real block device with async IO I might have more luck? > Just a guess... > > Or perhaps this code path is a corner case? In which case, perhaps its not worth > adding the batching optimization after all? > > Thanks, > Ryan >