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 E82B3E7F12E for ; Tue, 26 Sep 2023 21:19:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D1468D004E; Tue, 26 Sep 2023 17:19:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 75A578D0002; Tue, 26 Sep 2023 17:19:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D3F58D004E; Tue, 26 Sep 2023 17:19:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4950B8D0002 for ; Tue, 26 Sep 2023 17:19:25 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1C47B1C97A6 for ; Tue, 26 Sep 2023 21:19:25 +0000 (UTC) X-FDA: 81280014690.17.05DCF4B Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf20.hostedemail.com (Postfix) with ESMTP id 57ACF1C0018 for ; Tue, 26 Sep 2023 21:19:23 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kI6QY1M+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of hughd@google.com designates 209.85.219.177 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=1695763163; 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=ftGtzNCK4oOVyfSI32wzRjgE/k4q/Apr++atuhh5XZo=; b=VNQrVzenQZkDj0robAGBIXz4lvHxoSU6aoboJL5VPUKh1XbZwr+ZMKZa4a+AixIWItmhzX iaOdJ1wCpPTOOFRSrmfilKer0eXNrnsyLCuj5oEYPNKhmtbCscVW3P7XfxOINnnJZOaa1H riLKjs9GuOWzO5NxrxDaBZzbVzqdZV8= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kI6QY1M+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of hughd@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695763163; a=rsa-sha256; cv=none; b=Cw2OOUfLohimfdXV/NZttufh1Vry7QEqu8g7OSi/L0L68gV55+IfmwSulby6NzEPMl0JeR Qej7mJSnthgI9X52FEVXyRFVSiAFWmEYaavKSj/57yjqC6c1g1D2zMmKLE7A9TfD1rMc7P DG+MKimgX3WeE8ToIpxj450tsmyHuAc= Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-d7b91422da8so11285990276.2 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=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=ftGtzNCK4oOVyfSI32wzRjgE/k4q/Apr++atuhh5XZo=; b=kI6QY1M+iDNcnX2UQ1UOKKLDxZ58bVKkgtcsEN0fjb9tL5rk58fRIHS6X1aLqzg/e7 m1tfks3amjLuEsNIxfyQLuYQqVuJU7zS9KyO52n5vP8MH1WnlFekaylnMgEPfuSl5Kzm T4AEZGQCom2dCFb34Tizc3g5uJ+7eVJBiZdBJ48y4YlWx+Mg9NvfdamqnZIRrWJOYiN9 GCYV6z+QjaDrWAUDzoCb+62rRw4UeD4kS6Pxwyehnuf3sXuPOMTlAlYLfzyG/sxTUmXC Ku5PNrG/lRdAo8q79sTJAUC05Cq5pLXrY3givDMA8nU3ela+kZVn6ao+SsMinj9f1utJ c73g== 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=fq6sPk3yIpZ7y5WUlASGDfNyftwvF7vHwhmFy8sBx33jA0Hku+ubuflEAqdPuAURdD bG56iEgOkBc8Wdl/nAT1w7q5drF2+1JcmQlCqyCwSBNyfr2wBYBZF9/namhaYqSKqRBR C8/j3z4ZrAGYLUX/bQqexk9FhpWj9UngaLnWlIQXaWKdCaBz08VRDvJhzeJEtkOn4aqP TEHG0GFGd0DkwwXCkQrxppg7cL5pRRZChUPNV4f0rc1kzxm29yifcEn3iFgMW4fth7bK UvdmMPzrT4ZajZ06SdwAwJbxmOr/Xe6irXuQioQ+10ORe1DL0EZSTNfiOFXL+AIs5dcm sMgA== X-Gm-Message-State: AOJu0YwudSTZkUvZz2Uzphw58bzzumpQTSeCjC+XOjV5tVSJB5RMOd4i v+g8KOB2F4VD9FEbd7QhYbzSnQ== X-Google-Smtp-Source: AGHT+IHJdY1wmNInDIr3Oy//S0QP1jcTvv9Z3r8Gyxv3cnk9f+nHFsEK/rkIdCxcehiAZPiChY9+BQ== 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-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 57ACF1C0018 X-Stat-Signature: cuq64ifzftnwddutgnuaktqtne59dmnj X-Rspam-User: X-HE-Tag: 1695763163-965865 X-HE-Meta: U2FsdGVkX1/p2WORHw+idAUaUJBoVugeL9wsrBLm4Bcr67j/kVPxxDHJsRwb9optQi/OhTeAZemlvUuaqAQmBDYgz8x12YX2YzZVOVQAWvOcKJoRvi9tjgIXhxXkmscRzGnd7JtNEK/5MOUS85B3GqmdoKZnmDIJElO/tIaMGAsbmqwNUSOKJhpDSinsoiRpauXbo/L+JCZZqv/OKjum8Yecyr02cBFroyHq0jaAU96MPU0UgJYo7S8Hua+Mbi7ki/iu0+J0hES/yU2OTd8PvocNsXA5r8ct+H1dFdV1CSrJBCTmnsEylHgLeboLXsPRHIUwZD8Tg9so1tk9nC5vmwZxuwalRUtS6Gs919Co3Gue6FEY2Lqt5RJsZSu8t8oNp4atm3Uxjw+4fchU5vqdeSVtrBi82iDDupTKsdurVEkAx2QovEeEgIEZ4DrSxeiTuMe2N8G57uvdOx1OOAK17w/w4R/C8ZZDu3X+FyQZ0eIBPuXrRkOLJ08ml/Xjq4TaRrSWZhmd1xlQ1Ski64KSOkwjlto9WpRvEG4Iso/4bNaitKJCN1dvADwluNDQT8VMj7IhPz3uupNFrv6r8KEMfeWLj8jpNoBCd4ZFcPrGkbLMhNIjUVI8tF6YE6nE8ETxDUW885OwEsEshQyUssBhBO2sXhy07rOJOPyN2t86yyiHkI6Bwy5BUOltDoGruDZTkZ1nFn9QATKe1DkP9RImY57H21xQwhWzaB+H9tm+CLpICHHDqcBelt0Ou1vm6JYfqj21WIEl606yWcR5hMTuFFE+sro0huBxN00Zid678XBXarDg8CWsv4PUIXIbRKQd3x8k0B3r/QilIw2Ng3LZGuONgsxZWU4YgH/80xdWscpT4ZK6ivj5pqiO78S/gAtWo3k+q0tyAyt+SHry7MNyh3RFd72VfZNPsylDm5V5kEfSuPcWT6iHDFtVLnYPAwbNCfPHvhb1azRvN6pKrPa C4PhQDYX WVOOtuSya8nNrWY28sUwirl3dPsy/KdEfJ0Omhbgaxfhh16SLBU2jQox7ngg0uDtEvd0FRYH37lGUqoJ7E8OVtzU8iXF+NBLCyFAJIRCsR3d2DNigGPpXIx8YxFAVB31FodcDMT94020jxGKreJJQFDCGCXCE4L5rl5wCRwB2Jnq7llJvj9C4nGr4XwzT6WpvMqYrd8v6VNk6Lm6QRDeaEmSLTcMMn7T/0avS6lRA5SOlX9bLNgKSE+zWjvvIZfHlbFas8gEouShlVbHu38B3T/3WjotsUStyKCwDzy1pigREQyyrwTS3LKcnfQG1BIDottHstO1kOsB2eKSsl+VQ/VZ9jg0aV8e/Iyfd3dQbuUqYlrWNBvfSSkYnzX5nHIohobteMtQTVNMrict0ZRIYkd6PcI8F/WVGnlJ2uNxt60cDnjc0aLANYLjZ0I5Y58JzjyETM1plZN6cd24FO7NL9t8WOFqeWlUaus5y 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 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