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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E09EECA9EB7 for ; Tue, 22 Oct 2019 21:31:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7CFB021906 for ; Tue, 22 Oct 2019 21:31:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="Kpeg9R3G" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7CFB021906 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id ECCFE6B0003; Tue, 22 Oct 2019 17:31:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E66646B0006; Tue, 22 Oct 2019 17:31:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D54196B0007; Tue, 22 Oct 2019 17:31:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B73986B0003 for ; Tue, 22 Oct 2019 17:31:33 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 485AE8249980 for ; Tue, 22 Oct 2019 21:31:33 +0000 (UTC) X-FDA: 76072717266.05.month46_81dd02c560b34 X-HE-Tag: month46_81dd02c560b34 X-Filterd-Recvd-Size: 4999 Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Oct 2019 21:31:32 +0000 (UTC) Received: by mail-qt1-f196.google.com with SMTP id w14so29083233qto.9 for ; Tue, 22 Oct 2019 14:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=98G4icOId5gRa0BO3+NnJk8SaIphOMOAkR+jC8y01cM=; b=Kpeg9R3GFL4QkfZagosY6d53cYjLfU/55y5oiGy1mjM68ATS5EsPMC/b39+CZvdWeM 8ibBRJ3iDRpWYJTRT5OE2MAc0HRbHMm595crY+xLwbBHRUMsTGMIbg0AntoeOMyUCt+/ L8qKG9XzwfuKXthd76s7hR9+ewQIJGi5UyQFtq3Us7KZpuY4HdPH6MW0y0ZEnYa/9c63 ZO4/9+L5Y1ZazxPGB0LMu0hJk9Ap/Z0UgVACp0+rsSjXaz0Ac+1uW4mdQ3ZHCdSPFPXm t7w3cYhZSB217CYGAzMq3ziGNwSN3kVFOgs5o5kvEn100lxhMNAhcgNpDaiAD2pOTogb u82Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=98G4icOId5gRa0BO3+NnJk8SaIphOMOAkR+jC8y01cM=; b=pk9GJWCx0x82bynti/7hSZpR/16Oo1IITC461ZJ9xC+Hbk6nbBksL/YmDFOy0D+oSw Rot34EDLX0Vd6Od9D7lAmzw/GwZZZEwiK2sHWmPLj/wXlRHAfgauiyDUL4P2UZfdtl9j WJPoZqbvo+OpwHNycrvFKH1KaO7pCLAU5NpkNANRhXiKsP3wToyEOGucwPxTNqJNbA1F dK1y27m9RP9qmSn+zkyQp2E6tzoQO+3wJG7RghTkJh61QEpxjNdj7naI63Z0Slr+G8JN /EJNk0cvujFtz5HTJMlCsEQaIbnpqBHkHMDAE+IMSLmiovcdwGJzF0vy9qg++KBYT8OH YUbg== X-Gm-Message-State: APjAAAU0eNr2GkPmz8h7wU1o0MMUbpdnV29WTyONrktNfczjYBUYhEwT hr3UmyWp4j70+c1Jf3LU1ZptBg== X-Google-Smtp-Source: APXvYqxtoQLEP4BL19wiGwuyRPuynHQIQ7Fa6uLZDQMbflk5fVafKu3TQVjiuhiZwrorgsPiF32wZw== X-Received: by 2002:ac8:f8d:: with SMTP id b13mr5674183qtk.129.1571779891433; Tue, 22 Oct 2019 14:31:31 -0700 (PDT) Received: from localhost ([2620:10d:c091:500::3:869e]) by smtp.gmail.com with ESMTPSA id d39sm7220087qtc.23.2019.10.22.14.31.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2019 14:31:30 -0700 (PDT) Date: Tue, 22 Oct 2019 17:31:30 -0400 From: Johannes Weiner To: Roman Gushchin Cc: Andrew Morton , Michal Hocko , "linux-mm@kvack.org" , "cgroups@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Kernel Team Subject: Re: [PATCH 2/8] mm: clean up and clarify lruvec lookup procedure Message-ID: <20191022213130.GA361040@cmpxchg.org> References: <20191022144803.302233-1-hannes@cmpxchg.org> <20191022144803.302233-3-hannes@cmpxchg.org> <20191022192456.GB11461@tower.DHCP.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191022192456.GB11461@tower.DHCP.thefacebook.com> User-Agent: Mutt/1.12.2 (2019-09-21) 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 Tue, Oct 22, 2019 at 07:25:01PM +0000, Roman Gushchin wrote: > On Tue, Oct 22, 2019 at 10:47:57AM -0400, Johannes Weiner wrote: > > There is a per-memcg lruvec and a NUMA node lruvec. Which one is being > > used is somewhat confusing right now, and it's easy to make mistakes - > > especially when it comes to global reclaim. > > > > How it works: when memory cgroups are enabled, we always use the > > root_mem_cgroup's per-node lruvecs. When memory cgroups are not > > compiled in or disabled at runtime, we use pgdat->lruvec. > > > > Document that in a comment. > > > > Due to the way the reclaim code is generalized, all lookups use the > > mem_cgroup_lruvec() helper function, and nobody should have to find > > the right lruvec manually right now. But to avoid future mistakes, > > rename the pgdat->lruvec member to pgdat->__lruvec and delete the > > convenience wrapper that suggests it's a commonly accessed member. > > This part looks great! Thanks! > > While in this area, swap the mem_cgroup_lruvec() argument order. The > > name suggests a memcg operation, yet it takes a pgdat first and a > > memcg second. I have to double take every time I call this. Fix that. > > Idk, I agree that the new order makes more sense (slightly), but > such changes make any backports / git blame searches more complex. > So, I'm not entirely convinced that it worth it. The compiler will > prevent passing bad arguments by mistake. Lol, this has cost me a lot of time since we've had it. It takes you out of the flow while writing code and make you think about something stupid and trivial. The backport period is limited, but the mental overhead of a stupid interface is forever!