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 EF20DC54E5D for ; Tue, 12 Mar 2024 18:46:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64DD78E000C; Tue, 12 Mar 2024 14:46:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FCA38E0007; Tue, 12 Mar 2024 14:46:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C42A8E000C; Tue, 12 Mar 2024 14:46:12 -0400 (EDT) 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 39B348E0007 for ; Tue, 12 Mar 2024 14:46:12 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0B9671C09AE for ; Tue, 12 Mar 2024 18:46:12 +0000 (UTC) X-FDA: 81889266984.26.EEFFF2D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id CD26AC0019 for ; Tue, 12 Mar 2024 18:46:09 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=M7gGuWaW; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710269170; 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=9dPWFQZKFxOBV609wPw0UwjsnfeIQucQ3utIsVTuRT8=; b=jy3Fn8eov/7wiDIg+odqVAL3wGykC8krh/u2ceyE7cW7FfZ9+oowWpYq0LkDi0H3T/+1cM zyaOuHbdw+JVuEQvJs+OlRagPGoFm8Ie8KHqZKMvilpdjL4tgK6lul1hOGihN0PMivCfE+ co9cgGLCk9kYHlF/P5mR7sGLS+XQRRo= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=M7gGuWaW; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710269170; a=rsa-sha256; cv=none; b=ItROK1JStqYqSp6ICIkg17OjR0roWvPWPmYqAvckOgm1ihM6Kq51dxCPsSb+N2rprd7tp7 ASntNdkTVbnfFg9/mMAwvbXU59oDxBb6fCCezK54GXjGpmtycCylRXZrzwxZ7KH3kFdgUC UJMhv6Dt7G17zIlNh6q/P5LSmgdT9GQ= 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=9dPWFQZKFxOBV609wPw0UwjsnfeIQucQ3utIsVTuRT8=; b=M7gGuWaW6XSjQCrIYc/NbhvapB m/szHalFmpcEHx5ulycUwsIOMQgD+J/mqOiu7A9DsHnUITwR7vYeReWjkCYww0r3twXiG6lUZcieg s9DV6CG7Qj6kud+VvLszN8mqiS1jUw1+kmhtJugkGsQJQgIrui6zjYa+JrU3yh5kUrWr+4Gt/x4eT Fk1mtGqYg37/Bqn+Q2y1B7rsIDF8IudiiZoWpJVKDTGUoVOaugicAJwbd6XXm8kwhPAp6YRyuLA7u 3LpmxpP15QmXmS5InXlkmzuDxzuDi+wg3zzhaXFg8e8lsOL4uPmaZj+I5iUyJipfdrUFtKPJwXAYV PQ/OD/bg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rk78Y-00000003fIK-2FZy; Tue, 12 Mar 2024 18:46:06 +0000 Date: Tue, 12 Mar 2024 18:46:06 +0000 From: Matthew Wilcox To: Zi Yan Cc: linux-mm@kvack.org, Andrew Morton , Yang Shi , Huang Ying , "\"Kirill A . Shutemov\"" , Ryan Roberts , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/migrate: put dest folio on deferred split list if source was there. Message-ID: References: <20240311195848.135067-1-zi.yan@sent.com> <74AF044A-A14A-4C66-A019-70F8F138A9AB@nvidia.com> <76BBDB5D-9D40-44EB-A996-767404B85BE0@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76BBDB5D-9D40-44EB-A996-767404B85BE0@nvidia.com> X-Rspam-User: X-Stat-Signature: izr4mhhucjeppet51nt1hs8ujtidiq7x X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: CD26AC0019 X-HE-Tag: 1710269169-77479 X-HE-Meta: U2FsdGVkX19vZTFEehovIbn7bIQFDTukjgvxjSl3y7dKsOA4afK6IrGZJFXUNqdHOAfOeiaA8z/R2FRqTQ5kub94+vr6Y2CueXfVmpHD20KZelQuGGgjA+TvM+1T/P9y9zD63nL0gXS3qgvajR2AnIAedZFdMDROustAsy1UTJEG5DrEU3WdoTKE/oeZfzuq9PteczUZc6OxYnr20bEMjgv7WI49wmW8XAe16Hc8rK95I7A3a6sULepMyFqvv6eobpLVQO2eKA7YNArI/Z1xcsKWt6zmqGJr79uGMfx/BKDmCeXxjsAKbjItFDRYx7Nli9ElWtqUghp6IdcPnIjMpdY/ipQQw3DPDMu2Z7rO3AitniQrYFBcdR8gmvzSAFmFTKWcUv++dB3vbf3Lr0GiCyoVTFBAFjuBO2K1FiPCniKFWY38uNkBVWzoOWplly5jEOllDWkmcPhA0KcNa0tglyRrapNgybGSFudw2T2fkRquFIwj0uBCQSGmjqAXBqBY3F9bBPuxAPQLCMCz3nLy+QH1/qoSN5hdMh7dP4I1f7HotyQMnIumjp2JULS10BZypSEgCJV8hE55qsd4nHVCsAzZShxhpnKCzVXvrgctAUIZiAVP/SByG+0YOI+NGy00rW/VWm/Z0fxV6Mdr89E+VobI38f0WbGQjba+oQ2xEe0j1ZbnUKASQqASC8cL3kvYo78Q+lu0quYoAQ2nVQzeoF0NixIVPc9MtXFrKq/S+lE+hJGk4SKnK+zfOA+9lFb5/Mp6NbXTsqaaL8rjongOz3NzuJTVN5ir722CDdGy1fYLxhODwE+aAPxKcBljpRgywZPzAsM28OEulYXhIGJRsQ== 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 Tue, Mar 12, 2024 at 02:32:43PM -0400, Zi Yan wrote: > On 12 Mar 2024, at 12:38, Matthew Wilcox wrote: > > Folios with a positive refcount are > > removed from the per-node or per-cgroup list _at which point there is > > an undocumented assumption_ that they will not be removed from the > > local list because they have a positive refcount. > > But that sounds very subtle if not broken. As an outsider of I merely deduced this requirement; I didn't come up with it ... > deferred_split_scan(), only !list_empty(folio->_deferred_list) is checked. > The condition can be true if the folio is on split_queue or > local list of deferred_split_scan() with elevated refcount. In that case, > the folio cannot be removed from the list (either split_queue or local list) > even if split_queue_lock is held, since local list manipulation is not under > split_queue_lock. This makes _deferred_list a one-way train to anyone > except deferred_split_scan(), namely folios can only be added into > _deferred_list until they are freed or split by deferred_split_scan(). > > Is that intended? If yes, maybe we should document it. If not, using > split_queue_lock to protect local list, or more explicitly folio->_deferred_list > might be better? To be fair, the folio can be split by anybody as split_huge_page_to_list_to_order() is careful to only manipulate the deferred list while the refcount is frozen at 0. I'm still trying to figure out where to document this behaviour of the deferred list that someone (for example, your good self) would actually see it.