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 46430D10BFE for ; Sun, 27 Oct 2024 04:43:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D10C6B008A; Sun, 27 Oct 2024 00:43:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 481306B008C; Sun, 27 Oct 2024 00:43:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 321ED6B0092; Sun, 27 Oct 2024 00:43:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0D2196B008A for ; Sun, 27 Oct 2024 00:43:25 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4E760ADC3B for ; Sun, 27 Oct 2024 04:42:42 +0000 (UTC) X-FDA: 82718137362.19.B97DC41 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf01.hostedemail.com (Postfix) with ESMTP id 71C1F40007 for ; Sun, 27 Oct 2024 04:43:05 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=z1Byyj6r; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of hughd@google.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730004087; a=rsa-sha256; cv=none; b=Xdx9/IjnWnwnE+ZJ8y9u5Tn8yRwMZEUL5bJyoXWWLn7LLn8Uu+3xWfIb12iV5um9eCqZP5 TScHrDoLSr8I7jc/vHkCVZ4OK/LpHPTNZR/gum6vJhapUh/KnHFnFBJ98TKyrB5GrmlXCM cMbJ+xJtlSxow49BgCUndm1Y6YSnw3w= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=z1Byyj6r; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of hughd@google.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730004087; 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=MxJ7jTPYF7MJ+n+x+vALmSMEUZ0wIVJqL5CFxRxgP8A=; b=Y4dAjgj9gn/FbL6MFgS+SvYMpsa/WtnQMVu6I2huWwjgKRCKZuhFRlxlDABIZxTNECIpqA iB/hbk9DKH6pk3WUUiGq+vZRvsjE5rQVSdNqINLu/rt3MPf6PIW8arSf1oRl5pzeTp7DvO pQvXOCJqlrOlKoUJi2JH8XBYzZ2qWa8= Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-20e576dbc42so32947525ad.0 for ; Sat, 26 Oct 2024 21:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1730004201; x=1730609001; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=MxJ7jTPYF7MJ+n+x+vALmSMEUZ0wIVJqL5CFxRxgP8A=; b=z1Byyj6rdjHim+Qfu469spzv+jjLCpkH9w/LCTHOVcOmoOlwpccDRmNQAH+aoC/lPX l+TwEGSoJC7/EsKkmQ5uGNCRkhjUHd+x9TgOrwCsZeCfsq81M8P4/FgbxfU2epAFwda+ dOgQz/AwUByu543ll+eYBZNTtHRHzvBlr1NnQYVUFmq6Buv6zdoD5UcqfPRTrXrDD+6S 6wTt/fMXV88qe09/V3i+pjdQzYrqhZ6E6NfROpm6Mb+Z7G3fkMcrvN8kcH4DTt6z1Nov w+0d84+vuLPtBRKS6w2a5lyrKPJuXob6G2qEqNTimjLfwiwlr4VqMbaG6sV8tWq8lmV1 cjvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730004201; x=1730609001; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MxJ7jTPYF7MJ+n+x+vALmSMEUZ0wIVJqL5CFxRxgP8A=; b=HtDHkBXX3K1lFcDGMAp294Asx9WAt0VcRiNBsbN2n0o73qsOvc6HDnbuCOTt8fYA/j myCeNT0ndVvVv9LFUjFRITDBhxw3TdQ5s097PVQirXTZZuJgPiYOtMmVl6e0cXB6dyLI vRdYkuq2DXpUsSofdFKJOBYKgnuns4gNMteVF8bRGE5HdyJyfvUHExJM/HXWNwfInNxP 31FG2oHNeKa+k0Rj7ZfGQBaxzLk2SQOvc1jNueUA4RdNRP1jMk+HOAYoPEVBEdLwwjX9 gMMcAxs33bJYLAmMZitAZ3D3OMT2MpDXphJLPQVOohVEQzqwv8hXl2GuCjtSSzEhYukY ZPFA== X-Forwarded-Encrypted: i=1; AJvYcCXYutAFNVtRH8TusYEZmz3aim5XYpF4sab6fihan2OzxZ30cCRJpIaGLybOUvaJwSO3zaBXpyDT5w==@kvack.org X-Gm-Message-State: AOJu0YyCS7kryFFyCI5ZTXUF5XBkaGpTRSbQvUUPXFzwg6VAbD8TJp8g 77kp2PjSZk95ogt+7JqQJU9v6HZ8/dmgKX2G7SK2dly431L0FsME3OOhMW9XfQ== X-Google-Smtp-Source: AGHT+IFoimWn5iWOVL+r7Tuqqyu0INnrIinhsFyVKabz7kFPstUFS6IMfI3GNvN+lNKp/poVnkhlRw== X-Received: by 2002:a17:902:d4d0:b0:20c:a44b:3221 with SMTP id d9443c01a7336-210c6c08b12mr52868115ad.15.1730004201071; Sat, 26 Oct 2024 21:43:21 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-210bc04b8bbsm30616895ad.244.2024.10.26.21.43.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Oct 2024 21:43:19 -0700 (PDT) Date: Sat, 26 Oct 2024 21:43:09 -0700 (PDT) From: Hugh Dickins To: Zi Yan cc: Hugh Dickins , Andrew Morton , Usama Arif , Yang Shi , Wei Yang , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Johannes Weiner , Baolin Wang , Barry Song , Kefeng Wang , Ryan Roberts , Nhat Pham , Chris Li , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH hotfix 1/2] mm/thp: fix deferred split queue not partially_mapped In-Reply-To: Message-ID: <947f23e2-c817-b714-57d7-c893aad5002f@google.com> References: <760237a3-69d6-9197-432d-0306d52c048a@google.com> <3A1E5353-D8C5-4D38-A3FF-BFC671FC25CE@nvidia.com> <966a4aff-f587-c4bb-1e10-2673734c2aa0@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 71C1F40007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: sxoax83g7ripq3zskyn4nnrh1t1q1gnk X-HE-Tag: 1730004185-412056 X-HE-Meta: U2FsdGVkX19FELEMXojHJYzM1ILo78uMCt2HndBtqKloixdZEKs50te9udojPD1Cl352DIU0bTRgiXrMRb+TfBF7Fzi8hSVIccZ3Stx6D5lK8lrMY4SQw4RrfDKEX1iqGXabVs6W3BAvdtHf/k2wFqDMC3p0gbUWIgJCG47QReKLrgtU3HiA6gij6xz1rHcGKoSl2PnQnKWA+cCjd9m73b1LVUSXPJHdzVtVQAR4ppvsY8Q1xhABIu6fk0NoH/zW0deqNGRSx7XRUbdaiOXHbh0ZmVg7NESAvaw2eI5SVPvQ6949MBBZkAu/LeCkqneBCJ8B9L2xfgQTSInuMzq3I2YcHxWA6QRsy9U383N3MoVWKxuPUIOwwSEH10Ap3gi4Tl5IwoAQjDJyrm/hRBIyqlebKw5z7wy2aFs0zd8/8FjnHoLWPdHzRN8pJA+DPSzman0B7CBHju7AXuCpb6wS69yUcMDjFPX/kVO4aJMypBGRBlt+JzuknLQJCs7dUBxC4iqOjfz8+tCabQnmhok39nWU+gJyoxfvA8qnJ4YwEblvekS4kI5oxinCBwZ/1DoE0q5SMUiGLa91B2bB6q+9kvVcbt6WLiS2cdQGHUf3iapsSdCXgdUwzr6AOvYzz6CQy0GetMvl+D/vFu/Zfb6mNQCAOLSt3zo4Fwhq75s+pEuO/WCc6ZvDl6mQ2zLlTPcjUQZai4KP9nTghNNnmKVV/tmWd9JfJiPHuLqc7iAUuwEx9svDpGE/sFvfhSdvEnuyPdeKETR4cLRKswrl1xpKZrLI+bx3Rat7daOvsrZCvC738xA3oSPL89arrtj0LJ194O8f3rLvVxpJ2sho6VwK1EFJTg4MvKlSZuVCA76ZQn72It6JbKx7GZSnYSZT7u466Row+axva0xePXlq/kLKxAa5CjEMdwg41DhQJoGdjoo1lsEczdOLxYmpYkQfSjs0juAhQgjhY6qtqZR8yyp 1UP4P50s iWPn/Pfm8GYnRYmQTw2X+JcleFSauKwlKmAFBzbLI1Kk0wHL+0fXc0Sj34WxoDOVZLDRnyfrHxRvGc7T6dHMtt4GfW2m1YR3fW4khLaGcHDOfr5TOaTgv0vDJW3NMItG0E9sOP2Wd51SUN0pA4kvxnMguPLXN6DQwEJTNCNQqDf0M/JCedcxW3QNfdfv3hLN1RGR67S9Oxv7pZ5SAeH6j9kATgAHnOml3CjHQyyux8sRwyi+2Q/VwUcCB+XBfQqOi3u4aGoUsVcnsdoiTWmzGClDmyD8XCzjP7TvPpRdGnJfFgzvLHoAwyTvbcCOFys6OtQnzbG3wMEDAr3/s3JNh+CCp4G5ehOQe02hORJf54M1O/fj0CEwOk95zdEYnx3KL+l+r1a8AuzNQrphABlwKx6B3ntJokXKhfVmzh5nZ6LUJ76hYo42+jv/4/Kde0pTfqwJZ0Lu1+IC88mXPP6rWPw8MulRAsosQl8g/ 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, 25 Oct 2024, Zi Yan wrote: > > Thank you a lot for taking the time to check the locked version. Looking > forward to the result. The locked version worked fine (I did see some unusual filesystem on loop errors on this laptop, but very much doubt that was related to the extra deferred split queue locking). But I do still prefer the original version. > BTW, I am not going to block this patch since it fixes the bug. Thanks! I'll put out the same as v2 1/2. > > The tricky part in deferred_list_scan() is always the use of > folio->_deferred_list without taking split_queue_lock. I am thinking about > use folio_batch to store the out-of-split_queue folios, so that _deferred_list > will not be touched when these folios are tried to be split. Basically, > > 1. loop through split_queue and move folios to a folio_batch until the > folio_batch is full; > 2. loop through the folio_batch to try to split each folio; > 3. move the remaining folios back to split_queue. > > With this approach, split_queue_lock might be taken more if there are > more than 31 (folio_batch max size) folios on split_queue and split_queue_lock > will be held longer in step 3, since the remaining folios need to be > added back to split_queue one by one instead of a single list splice. > > Let me know your thoughts. I can look into this if this approach sounds > promising. Thanks. TBH, I just don't see the point: we have a working mechanism, and complicating it to rely on more infrastructure, just to reach the same endpoint, seems a waste of developer time to me. It's not as if a folio_batch there would make the split handling more efficient. It would disambiguate the list_empty(), sure; but as it stands, there's nothing in the handling which needs that disambiguated. I can half-imagine that a folio_batch might become a better technique, if we go on to need less restricted use of the deferred split queue: if for some reason we grow to want to unqueue a THP while it's still in use (as memcg move wanted in 2/2, but was not worth recoding for). But I'm not sure whether a folio_batch would actually help there, and I wouldn't worry about it unless there's a need. Hugh