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 0FB43C5478C for ; Tue, 27 Feb 2024 12:28:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8601E280006; Tue, 27 Feb 2024 07:28:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 80FEA6B0205; Tue, 27 Feb 2024 07:28:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68932280006; Tue, 27 Feb 2024 07:28:27 -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 541116B0204 for ; Tue, 27 Feb 2024 07:28:27 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2BEF91A0AB5 for ; Tue, 27 Feb 2024 12:28:27 +0000 (UTC) X-FDA: 81837511854.09.204AC4A Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf08.hostedemail.com (Postfix) with ESMTP id 81E26160005 for ; Tue, 27 Feb 2024 12:28:25 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf08.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709036905; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+v0i1ycJ36k2oTHkqCSbFT4XFUXdun46BwfRlrUBnMw=; b=i88ptua6qngP8loxIc0xIB6FXtrSkX7NOz8Cl7AnVQfJASDW2rIoiGAs4WmHZ7Y1agK8Hh e268n3/mkWEnXgBdWZqzqH/WklsHfuBcsnWAyhICCVmmp0Y0Sa6iUf2Qc3ADgrXQNWwXz1 Vrg33UD4jslvJpwUYt44lXjQr9SPoQg= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf08.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709036905; a=rsa-sha256; cv=none; b=A7HtNQyXMZvrT4Llljm0sBY7UbbRb/eUUsB34vlwt+cjS2rDVRuz8Yh/anUqGCYoc4N955 2LzjfSY5fN/JHZO9cnJZvZl5RM6dCJfm7zByR+oANf8jDYBY1+4jtFG7UuTQ6Gb+Mb90fa q5T6UWUwq3rjOH3a2Q0Gpv0gMj+v8T0= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EE29EDA7; Tue, 27 Feb 2024 04:29:02 -0800 (PST) Received: from [10.1.30.188] (XHFQ2J9959.cambridge.arm.com [10.1.30.188]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 54C993F73F; Tue, 27 Feb 2024 04:28:22 -0800 (PST) Message-ID: <6caed7a8-6a76-4957-9c24-f59b8259b526@arm.com> Date: Tue, 27 Feb 2024 12:28:20 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/4] mm: swap: Swap-out small-sized THP without splitting Content-Language: en-GB To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, david@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, shy828301@gmail.com, wangkefeng.wang@huawei.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yuzhao@google.com, chrisl@kernel.org, surenb@google.com, hanchuanhua@oppo.com References: <20231025144546.577640-5-ryan.roberts@arm.com> <20240205095155.7151-1-v-songbaohua@oppo.com> From: Ryan Roberts In-Reply-To: <20240205095155.7151-1-v-songbaohua@oppo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 81E26160005 X-Stat-Signature: 7a1pxgop8aohgn8ka4fzkummw49gmui4 X-Rspam-User: X-HE-Tag: 1709036905-857241 X-HE-Meta: U2FsdGVkX185UaH8gvcH4Z1LtWnXvtzz70xh/4Z2y84q6hvlOfdAhUw4dSCZsMTI5PEWdQRokdmrHPROZEAZDppaiIi/aX/DOhWUWseCrfWuY6OI2y7zOKA9ctER7BLfG7RMl2vAJUH0S9zbLzmzccrH9PQ/BV0IwF9hBwtSMT+WrOZUlj3YR3eVCSRnAgA9kG2c4Nb6v83+zth1CYL5g4aX8V/s4zgW2QS0PLSNktNrQzndPG7ixxxMyvbz0en4rE+HL02cufK83nH4jz39mnrsWqSlNVezZh5Q4IXdlPdrhtg0N58+BesE5+kzqJ/1Q0vyVelG/dDc1YafPBFt4soPQc/zADjB8XHK98BhJ1QtZMymXmrso7CDEf6VKpBy+oN6FqmwbY4B90GjvrNE3eBO2EB7QGBOVPjocJbKJSI16+nAZ5PybBXTQKb+hC+On6h8n6Ci5lO+ZvO+wQpUrbdxjUN+Ip1mtXNq43nfeAJUQmYBJMqlIMbkOdaKSojeesghncLqlVn22KIekUIBxgRjh0Yheg49+idWY2ngWGRXxmOa6UqGJwEev2nAmjpBWLEFRJdCRhLnJbAbhN4MxK12W8ivV2lI4Z83PYPiw0ymsgzMjXrYviOx2Q9IfUo0v9yeu2CUELmKrQmwUGkL/QtwDKZ187fDKvJO/rVcKgDmkgHoceG5Q3iKZxpW1HIgO4+F1NYUOjkK4jqj6B/vj4b2hAQFl/vlq5qCiOMM/Mg3lJZBAUV6i2ubBDJsW5xSWqy7j1kL2Onae2XewYawGcJ+9IQLLgL2mbyektOD1LrcCzRireMxayvcg7K9akC3h7k8aKPG7M3iR01l//BCgeILIFfmL5ag 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 05/02/2024 09:51, Barry Song wrote: > +Chris, Suren and Chuanhua > > Hi Ryan, > >> + /* >> + * __scan_swap_map_try_ssd_cluster() may drop si->lock during discard, >> + * so indicate that we are scanning to synchronise with swapoff. >> + */ >> + si->flags += SWP_SCANNING; >> + ret = __scan_swap_map_try_ssd_cluster(si, &offset, &scan_base, order); >> + si->flags -= SWP_SCANNING; > > nobody is using this scan_base afterwards. it seems a bit weird to > pass a pointer. > >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -1212,11 +1212,13 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, >> if (!can_split_folio(folio, NULL)) >> goto activate_locked; >> /* >> - * Split folios without a PMD map right >> - * away. Chances are some or all of the >> - * tail pages can be freed without IO. >> + * Split PMD-mappable folios without a >> + * PMD map right away. Chances are some >> + * or all of the tail pages can be freed >> + * without IO. >> */ >> - if (!folio_entire_mapcount(folio) && >> + if (folio_test_pmd_mappable(folio) && >> + !folio_entire_mapcount(folio) && >> split_folio_to_list(folio, >> folio_list)) >> goto activate_locked; >> -- > > Chuanhua and I ran this patchset for a couple of days and found a race > between reclamation and split_folio. this might cause applications get > wrong data 0 while swapping-in. I can't claim to fully understand the problem yet (thanks for all the details - I'll keep reading it and looking at the code until I do), but I guess this problem should exist today for PMD-mappable folios? We already skip splitting those folios if they are pmd-mapped. Or does the problem only apply to pte-mapped folios?