Received: by 2002:a05:7412:2a8c:b0:e2:908c:2ebd with SMTP id u12csp2259686rdh; Tue, 26 Sep 2023 18:48:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGRyM/nzFl5dx+D3TnZGcXh0Huov0sxPBVxvtTfIgCV2eTKUsSTq3t8cvwSKObo+YEuIunP X-Received: by 2002:a17:902:da8b:b0:1c5:bc83:557b with SMTP id j11-20020a170902da8b00b001c5bc83557bmr365563plx.51.1695779282793; Tue, 26 Sep 2023 18:48:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695779282; cv=none; d=google.com; s=arc-20160816; b=y8g7APz55/i+oU0nVmPtuZPS9nJZnwZxW49Ewsks3eZOghvLbd6gNQVSH2kw6X9aqM ur+eX//e065ZNCIc5cGkYm530zfNZFmU2E7EZ8oWP9bhKQ1VBCjB+olgPMlcPjX4QrW5 LOBOJD0DbCqg8aVIwaJhk3EOJKpp1Ni1zsB4SlOu5JK/f48uIyjArLEIKI5E4bTJIHLw qxXSlAP3Hn1fKYVBD7r+pYIy8BjOecyOT2pglE8wElLuouDYKDsH7EpEfCaSQXFs5bvY cJpOZZiDxkaCEIpwWU+J3DNGG26ttEB/wk5hYqrqRK2i2Ujwb8lE76rwJQWynmLdDiB8 dyQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=ftGtzNCK4oOVyfSI32wzRjgE/k4q/Apr++atuhh5XZo=; fh=FsoBR+GRrPt051++g1DqnS429bL6eWE/AX+3WZndopE=; b=WQ+QbraZBTU7oWuefwIXWr7Qb6RuG6J+1hFSIoit9bQrlpcEjqORvSRkiX3bjYKtrI Mf5fmHh6rB1OUDUMwB6yc4jmnuS3qScFJsmVNh53jwCUy2ioAUQRSr5G7Div9GKOPGPe g598nN8+2DPkqkaWlceaXe81cCwQvUOe1eZkPqXSiJoMb6YrECeExek5HxEqq1wUvK5N ahQCU2K+eRtue97rCK16ATuejOzksCk+eI3klbbOeYWaPDmh53w9rIDfPyqv7g/oD6dr NenmOBpRk7gSfbsDyyubMI+V/AnjafW2brF8v9t/THmhf6gXqup9ZyEYqIvlA/2P6zl1 niPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=oqbmQ2iW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id h4-20020a170902f54400b001c6240dec44si5401901plf.389.2023.09.26.18.48.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Sep 2023 18:48:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=oqbmQ2iW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 719A480A1E1A; Tue, 26 Sep 2023 15:31:59 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231765AbjIZWbz (ORCPT + 99 others); Tue, 26 Sep 2023 18:31:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231817AbjIZW3x (ORCPT ); Tue, 26 Sep 2023 18:29:53 -0400 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F3167A9B for ; Tue, 26 Sep 2023 14:19:23 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-d81adf0d57fso11301385276.1 for ; Tue, 26 Sep 2023 14:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695763162; x=1696367962; darn=vger.kernel.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=ftGtzNCK4oOVyfSI32wzRjgE/k4q/Apr++atuhh5XZo=; b=oqbmQ2iW3+prSHhngWmo6ifuNGiTjPh/RvqFT87rTRCjnvHCI89GqhlERxopw3qsrJ B0f1tqXZYLDxasu3YPLMfCiNQfvl3XzFoWgjKbQQHzgcxXUm0ivFR0MmYF4zglvJkzjn kSGtpJrw8bgUAKXiqdnnuVTU3OSW6A75Wia29cjg8+Lx4f4C4hjIOwmrIHDPv2odusET WsxOzJjU9iR9pPcCdpnlO748mIpZlu8DfgXQWocqsVDBshhfqPOuKAvJXNdjiXPhY+fj 24cELyZjZkGJD3K2nBZqC4jKYAl5jekqwi+249MtiW+DrHKIkDXMjF4syFzQ6JnjgqS8 WZaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695763162; x=1696367962; 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=ftGtzNCK4oOVyfSI32wzRjgE/k4q/Apr++atuhh5XZo=; b=oZINtEqPltLm7/srLrhxegXVgU5gljzzNxjQq+00UCh/7a/ZK4nEENOORd9s+MiXT3 I/dxYqeR1yjPMcwqK2T6JjUYF3UTokmt/9Bb/rvCyO7258gZjOL7N9g3SnGa3hKW1wjp 9kSuFyzSEnYezcysZNl6UQH3W5CQXfD/dc6ij6qvHDhhDaijJfAHD4JPoVTIikQ6Xnd9 UiYaZVcZocP+p10jsVEBmUFhrImVfM0kwajK91f9ZAYNvTfDeVnhHaOXPO2WT71wiQsl pcWsfj4kt38Q2IeJv4ivcU83yAPdRms+TbEsu9f4SS7NN9WK2IBs9D3S1R8lv8IQDCBY 9eGQ== X-Gm-Message-State: AOJu0YzYxrISOh3C54H2rVTehGp0GlWRulfQJazeif0b0ysniVEPbeOB eBIjgTDFXxu7s2suPXMFiI2o7w== X-Received: by 2002:a25:ae17:0:b0:d85:22:8215 with SMTP id a23-20020a25ae17000000b00d8500228215mr117012ybj.34.1695763162392; Tue, 26 Sep 2023 14:19:22 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id b23-20020a253417000000b00d13b72fae3esm2959326yba.2.2023.09.26.14.19.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Sep 2023 14:19:21 -0700 (PDT) Date: Tue, 26 Sep 2023 14:19:19 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Matthew Wilcox cc: Hugh Dickins , Andrew Morton , Andi Kleen , Christoph Lameter , Mike Kravetz , David Hildenbrand , Suren Baghdasaryan , Yang Shi , Sidhartha Kumar , Vishal Moola , Kefeng Wang , Greg Kroah-Hartman , Tejun Heo , Mel Gorman , Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 06/12] mempolicy trivia: use pgoff_t in shared mempolicy tree In-Reply-To: Message-ID: <7191425-f87-99c7-58b9-d54169e3fe0@google.com> References: <2d872cef-7787-a7ca-10e-9d45a64c80b4@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Tue, 26 Sep 2023 15:31:59 -0700 (PDT) On Mon, 25 Sep 2023, Matthew Wilcox wrote: > On Mon, Sep 25, 2023 at 01:28:14AM -0700, Hugh Dickins wrote: > > Prefer the more explicit "pgoff_t" to "unsigned long" when dealing with > > a shared mempolicy tree. Delete confusing comment about pseudo mm vmas. > > Yes, with three quibbles > > > struct sp_node { > > struct rb_node nd; > > - unsigned long start, end; > > + pgoff_t start, end; > > struct mempolicy *policy; > > }; > > - > > struct shared_policy { > > Did you intend to delete the blank line between these two structs? > That's not our normal style. I think I did intend it actually, to join both of those structs to the "Tree of shared policies" comment above them. But now that I'm looking again, I think what I'd most like to do (and going against all of your suggestions e.g. move sp_node to mempolicy.c: good observation, but isn't keeping them together more helpful to the reader?) is swap those structs around - struct shared_policy first for the root of the tree, then struct sp_node showing the nodes of the tree (and still without blank line). Wouldn't that be the most helpful way to present them? I'll knuckle down and do exactly as you have suggested, if you say so: but above is my own preference. > > > +++ b/mm/mempolicy.c > > @@ -2444,7 +2444,7 @@ bool __mpol_equal(struct mempolicy *a, struct mempolicy *b) > > * reading or for writing > > */ > > static struct sp_node * > > -sp_lookup(struct shared_policy *sp, unsigned long start, unsigned long end) > > +sp_lookup(struct shared_policy *sp, pgoff_t start, pgoff_t end) > > While you're reformatting anyway, mind joining these two lines? > > > @@ -2499,7 +2499,7 @@ static void sp_insert(struct shared_policy *sp, struct sp_node *new) > > > > /* Find shared policy intersecting idx */ > > struct mempolicy * > > -mpol_shared_policy_lookup(struct shared_policy *sp, unsigned long idx) > > +mpol_shared_policy_lookup(struct shared_policy *sp, pgoff_t idx) > > Ditto Sure, will do (I recall Linus much prefers them as you suggest). But we have different indentation habits: I think it's spaced exactitude which irritates you the most, would the style below be okay? Or maybe you'd prefer to go over-80 with these two. struct mempolicy *mpol_shared_policy_lookup(struct shared_policy *sp, pgoff_t idx) Hugh