Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp194258pxa; Wed, 26 Aug 2020 08:12:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxiBTR2CZlDi9hZ8QO2ePc6so0xLdOv34DLD8qGXbx0MTOXThVoMjbPoyIECW9pB048u9gc X-Received: by 2002:a17:907:42cc:: with SMTP id nz20mr16532277ejb.429.1598454741860; Wed, 26 Aug 2020 08:12:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598454741; cv=none; d=google.com; s=arc-20160816; b=ZrELct7uvE8yHleN5g1JJP3limPflDqzQI8QiGw0en/69gljpvSxEUrG+X0vBhXfee M4HsWBLkmMX5anrl3Vwi9fJJxl2rXlo3D05Nn3xGYQm2vFPjlz/ySWQx1vz5zBY+nQBw BjH0T0j3enm8ydHdHJ9uPiDLHaJtAe6xGhm7W02ZazgwZVmnIjOseRLyMKyAd5sfZzPf iZ8aPr/dIQZyIG09YRKzSTpNBhbGexhNnARlQxGCFp8xG9ZypADEQWrTQmeiUhKTsbIK ziQWwCGTuYT5HVAaQJUvcaCWgogVwGD2TCvsiashRw0LgVMv5iIa9eWRcjqePPmkdnIX pB8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=vg8N6XsbIE7lvZX/pCZOFe+OtpGR0YWlM+DD8uHDUGQ=; b=zEriLw8oBd6FL6lq8EmPIxwbFoC9bpSgCzPyxywrt0mfgYSotJqQTxSmadjO4BdXQg tm8Dc6vmoKP75F5wcGdPhA/GUYnr9msI6ediXJvReNmKafwyX0OCgJtjVmDBdtbtQUfR 56vcs7nUiD9V3wl/9aBTHbglMyVanX7pFCtt2IgRbHz4ioT97AeMzkP095bIMUrSURMs Z4yBU7lDgsAryk0l/G9CZ08yoXfhZ80Ij7cyC5qsp1UJNDY9TVxPJYQuj6MLb69o/ikT S/tK7FmQfPeAxP9scKxRC3qvyvnCgEBjTjhlBp89RUOdpCVEj+WVkG6iPyJOnmAQQj/1 OFMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=VAOKpGG4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bo27si1629145edb.0.2020.08.26.08.11.59; Wed, 26 Aug 2020 08:12:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=VAOKpGG4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727063AbgHZPKo (ORCPT + 99 others); Wed, 26 Aug 2020 11:10:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726934AbgHZPKm (ORCPT ); Wed, 26 Aug 2020 11:10:42 -0400 Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 89A75C061574 for ; Wed, 26 Aug 2020 08:10:41 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id s16so1597940qtn.7 for ; Wed, 26 Aug 2020 08:10:41 -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; bh=vg8N6XsbIE7lvZX/pCZOFe+OtpGR0YWlM+DD8uHDUGQ=; b=VAOKpGG4Zi1L0nHk3pQChVy6LRCqLG0qD/7fwLdWBi9XbsPa+O7Uq2p7C7i1gtvxuF yUiWcAjIIr7W3J71zlqtWD7t2XecOSMv4Z8Vo9D22AEnwSYBdhp9bLlcsTyqyVT0PkOm 6lQsFFPn4vjC5shx4wLOdylw9FIQcFWlFd3ZTCqMXpqDORJ6S0UXlw3Q0fAoeya9nGcK 3KyT/337ybzoMJsqTLWcEEqoUj/7b0O+aIgq4feNby+j5A3AAgkMjCFhu93HxCQ+qRgQ M0iItYBDqEZWD0cxnCQ3JfuMG9LqTb1O1DvejdQunzJkmhaRRPNY6924yuSU0CZRbhW2 Mkqg== 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; bh=vg8N6XsbIE7lvZX/pCZOFe+OtpGR0YWlM+DD8uHDUGQ=; b=ZfCl+r6S7xm7Gs9M2MDLCPaOAgWz9XuGk6jhvmgmJDiwiXUi1gl8M9FUp0dnL+dvQX gdg3D2+cV5Xpbyu7A+Qn6GzCBbVc98do1HykWo86mcHLIxq99h+RlbFJEZrwfjbcRf6h gfbZ4fq1L+c7tJtRoYjzc3cckcmX+6+4zblrnDuCkuEfuMmeRkodWbtLS4HupMkR+4c8 FT9yUd167qR5jbmQ7voUjjr/zLyW4y1tu2utCvkJIX6Lej2AtHdp1rWt48si8dG6N9XJ 7KXZ3iKeWBTNeELMuUIpmTdtSpm5LkRfH6kV2Ju45I/wzC3FkMhLzVaCQuI2UK3FGJ2X ihwA== X-Gm-Message-State: AOAM533Bgu3EnYXAo05rJ1LU3Yyjsb+lw569QrFSUnSebbjYN5LJ4Lyf aOetLLNtz4AEintH+Ea7TmFUtA== X-Received: by 2002:ac8:1ab3:: with SMTP id x48mr3056695qtj.153.1598454640731; Wed, 26 Aug 2020 08:10:40 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:f52c]) by smtp.gmail.com with ESMTPSA id e21sm1802330qkl.88.2020.08.26.08.10.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Aug 2020 08:10:40 -0700 (PDT) Date: Wed, 26 Aug 2020 11:09:25 -0400 From: Johannes Weiner To: "Matthew Wilcox (Oracle)" Cc: linux-mm@kvack.org, Andrew Morton , Hugh Dickins , William Kucharski , Jani Nikula , Alexey Dobriyan , Chris Wilson , Matthew Auld , Huang Ying , intel-gfx@lists.freedesktop.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 6/8] mm: Convert find_get_entry to return the head page Message-ID: <20200826150925.GE988805@cmpxchg.org> References: <20200819184850.24779-1-willy@infradead.org> <20200819184850.24779-7-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200819184850.24779-7-willy@infradead.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 19, 2020 at 07:48:48PM +0100, Matthew Wilcox (Oracle) wrote: > There are only three callers remaining of find_get_entry(). > find_get_swap_page() is happy to get the head page instead of the subpage. > Add find_subpage() calls to find_lock_entry() and pagecache_get_page() > to avoid auditing all their callers. I believe this would cause a subtle bug in memcg charge moving for pte mapped huge pages. We currently skip over tail pages in the range (they don't have page->mem_cgroup set) and account for the huge page once from the headpage. After this change, we would see the headpage and account for it 512 times (or whatever the number is on non-x86). But that aside, I don't quite understand the intent. Before, all these functions simply return the base page at @index, whether it's a regular page or a tail page. Afterwards, find_lock_entry(), find_get_page() et al still do, but find_get_entry() returns headpage at @index & HPAGE_CACHE_INDEX_MASK. Shouldn't we be consistent about how we handle huge pages when somebody queries the tree for a given base page index? [ Wouldn't that mean that e.g. find_get_swap_page() would return tail pages for regular files and head pages for shmem files? ]