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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DDE0C4332F for ; Fri, 18 Nov 2022 20:51:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229861AbiKRUvn (ORCPT ); Fri, 18 Nov 2022 15:51:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229533AbiKRUvl (ORCPT ); Fri, 18 Nov 2022 15:51:41 -0500 Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0EFBF7615F for ; Fri, 18 Nov 2022 12:51:40 -0800 (PST) Received: by mail-oi1-x232.google.com with SMTP id q186so6613222oia.9 for ; Fri, 18 Nov 2022 12:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=Pnv/AcibuVlHkWWrn9NvH3zq6Vm135VxzOsOFf6QZKI=; b=gFXMFOqmW0RMul/DdKfwDG62G+ABj0IB78rq9gSetzwIaS+UPKqPErjDSsiBHWUQw9 NUVnruR35lTlrjm81tpWsPTyPAKpWIF/zyxVLwCKeNsy8a9o0Eyp6ilf+oJDMBfS045a ofgKIojFLFodw32oJYhKEar3+MZ2b8NeZ6e4ewYMv1sCAbr9GHTOjNQ3t7zRUp+WbMx/ LC6a9XZo2bfdC7hOns88AaTsh+vSSBw1OidcmcH2hPXIYOjMfgb7WSOUBi8zBYAjpKAV baC7D3smbTLQEzemCPraruuTbPEQDQBJA162eh3lr9jHUvZXK07+zPdenbqM8i5J28OE pL9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Pnv/AcibuVlHkWWrn9NvH3zq6Vm135VxzOsOFf6QZKI=; b=LRELGZEFEc6gFpYeIfkdLAsTsz8gtSpt3njNWuBhLjcxxlV9Wn5uprRdJaoataX17f 1p7fBmF2cGu1byAQErGMJdtNu66jswsAPLp8uqxdMoA7+U22i+2evs2vlbQLQgbKkts9 NnOhHbMtd9jhHBcdkEzVS+tFjB/gMflUQPH+aRT0zx6OG835RGP8zcvxgxp7E0qW5Qo+ vwEPdngCh5JfuSly1mGs2ErAp8xeXExoCJlgxjrklDYt29wVVhZVKRY6ONnoQrjM0E3F bsnDvNSKw62UyDg0Ne4nVhhFfhpIxTlFvXeFr+e4FXy84cD2zbFLoVxXRzzz3xV51KxT ug0g== X-Gm-Message-State: ANoB5pmaoS3eakTXeVZ6aIr8niMdIS2Xal4PAP5GsMg+8ILFogd5NDjC gTLTk1yRlFSpkvu+8AhCEs3h7w== X-Google-Smtp-Source: AA0mqf4giCJcjJID1X3/l1Gp967DEW/pJcOXomtJhqPGBJUF6GO8tkq6sBU2omWmjQg/pQRwcqgeuQ== X-Received: by 2002:a05:6808:1d8:b0:35a:3e6f:3635 with SMTP id x24-20020a05680801d800b0035a3e6f3635mr4570376oic.63.1668804699283; Fri, 18 Nov 2022 12:51:39 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id l32-20020a0568302b2000b00661b5e95173sm2012730otv.35.2022.11.18.12.51.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Nov 2022 12:51:36 -0800 (PST) Date: Fri, 18 Nov 2022 12:51:09 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Linus Torvalds cc: Hugh Dickins , Andrew Morton , Johannes Weiner , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Vlastimil Babka , Peter Xu , Yang Shi , John Hubbard , Mike Kravetz , Sidhartha Kumar , Muchun Song , Miaohe Lin , Naoya Horiguchi , Mina Almasry , James Houghton , Zach O'Keefe , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/3] mm,thp,rmap: rework the use of subpages_mapcount In-Reply-To: Message-ID: <93fa81ae-d848-58c2-9f70-27446bf9baa8@google.com> References: <5f52de70-975-e94f-f141-543765736181@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Nov 2022, Linus Torvalds wrote: > On Fri, Nov 18, 2022 at 1:08 AM Hugh Dickins wrote: > > > > Linus was underwhelmed by the earlier compound mapcounts series: > > this series builds on top of it (as in next-20221117) to follow > > up on his suggestions - except rmap.c still using lock_page_memcg(), > > since I hesitate to steal the pleasure of deletion from Johannes. > > This looks good to me. Particularly 2/3 made me go "Aww, yes" but the > overall line removal stats look good too. > > That said, I only looked at the patches, and not the end result > itself. But not having the bit spin lock is, I think, a huge > improvement. Great, thanks a lot for looking through. > > I do wonder if this should be now just merged with your previous > series - it looks a bit odd how your previous series adds that > bitlock, only for it to be immediately removed. > > But if you think the logic ends up being easier to follow this way as > two separate patch series, I guess I don't care. I rather like having its evolution on record there, but that might just be my sentimentality + laziness. Kirill did a grand job of reviewing the first series: I think that, at least for now, it would be easier for people to review the changes if the two series are not recombined. But the first series has not yet graduated from mm-unstable, so if Andrew and/or Kirill also prefer to have them combined into one bit_spin_lock-less series, that I can do. (And the end result should be identical, so would not complicate Johannes's lock_page_memcg() excision.) Hugh > > And the memcg locking is entirely a separate issue, and I hope > Johannes will deal with that. > > Thanks, > Linus