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 10FA5C4332F for ; Wed, 23 Nov 2022 16:07:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6426B6B0071; Wed, 23 Nov 2022 11:07:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F3096B0073; Wed, 23 Nov 2022 11:07:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E0FF6B0074; Wed, 23 Nov 2022 11:07:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3ECDC6B0071 for ; Wed, 23 Nov 2022 11:07:13 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EDC9E1A07A5 for ; Wed, 23 Nov 2022 16:07:12 +0000 (UTC) X-FDA: 80165186304.24.31E7FAE Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id 887BB100014 for ; Wed, 23 Nov 2022 16:07:09 +0000 (UTC) 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=sXPQl1YCs6Mf/k1U0Y2ft9SkDteXobSD5EsA9lUmMoc=; b=wK6p3Ixs4mi/OdEnPqTQiHQPWb DO57EVXUpyIl7hGks9JwF6K0xAph5UN4ZTuSvlrjIobF852T6qghB6h575mqOEqjgufwUzWtcq2Gv 5sooHj86ltRIuoSKDNz3Qcjwspl598rYwsmRr6kdGH9YMbbC+5sCZpJTJEWk3Ggb//DcPCPfK6eXX cbUNyEjZBM4xkbhxMAAOcPSkVPW0Px/kqRJw8T5P77fhCT67J2XmvVIGkGhpVNyCc1B7hsk05pYPi q8un9ay9sU4Op7tb6/wzJRftYQi4m4Sknal3i2gmJXLP91lW8qf0pSNRV/MGyBix/TVWuf/JFaKQv GPglhEwA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1oxsHF-007nFR-Hj; Wed, 23 Nov 2022 16:07:09 +0000 Date: Wed, 23 Nov 2022 16:07:09 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Hugh Dickins , Gavin Shan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, william.kucharski@oracle.com, ziy@nvidia.com, kirill.shutemov@linux.intel.com, zhenyzha@redhat.com, shan.gavin@gmail.com, riel@surriel.com, apopple@nvidia.com Subject: Re: [PATCH] mm: migrate: Fix THP's mapcount on isolation Message-ID: References: <20221123005752.161003-1-gshan@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669219631; a=rsa-sha256; cv=none; b=U8dCvLmmz3TiYvvAMSkSWgu6J5w08vignSnRaKpLx/2pqEI0MVPXw/2AlvJasxonuuKOSw UxrooB+s0FprqYM/lRoQMcRvHVmjxGORDZyKuOXQpz3ul12ogB4qkdqYb2qrg85YbQ+2+7 FI5ZqwsJgUQnqrFzN3NSmqn4sM+j48A= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=wK6p3Ixs; spf=none (imf05.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=1669219631; 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=sXPQl1YCs6Mf/k1U0Y2ft9SkDteXobSD5EsA9lUmMoc=; b=MtnEQF00+8tiBvHVHYvocI+Hosu7rjR3NzPTz0IPGTItSxLVl4hWOfMBkqJjzjrqyRJilH QrD3Ic8DhkIoNrWJRYZTAQbI3tJOwht+nFYNNiFZxtwIFBBsZ/sgCx7ZCOJfPvyUwkJohg whXFW3rvfo1PlIE5H7ZNgCDMILEmvew= X-Stat-Signature: fzzigqt9jkhhgm4ung3qey58nnhkrarc X-Rspamd-Queue-Id: 887BB100014 X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=wK6p3Ixs; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam02 X-HE-Tag: 1669219629-341881 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: On Wed, Nov 23, 2022 at 09:56:38AM +0100, David Hildenbrand wrote: > But we do have an even better helper in place already: > mm/huge_memory.c:can_split_folio() > > Which cares about > > a) Swapcache for THP: each subpage could be in the swapcache > b) Requires the caller to hold one reference to be safe > > But I am a bit confused about the "extra_pins" for !anon. Where do the > folio_nr_pages() references come from? When we add a folio to the page cache, we increment its refcount by folio_nr_pages() instead of by 1. I suspect this is no longer needed (if it was ever needed) and it could be changed. See __filemap_add_folio(): long nr = 1; if (!huge) { nr = folio_nr_pages(folio); folio_ref_add(folio, nr); > So *maybe* it makes sense to factor out can_split_folio() and call it > something like: "folio_maybe_additionally_referenced" [to clearly > distinguish it from "folio_maybe_dma_pinned" that cares about actual page > pinning (read/write page content)]. > > Such a function could return false positives/negatives due to races and the > caller would have to hold one reference and be able to deal with the > semantics. I don't like the 'pextra_pins' parameter to a generic function ...