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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 83342C433E1 for ; Wed, 26 Aug 2020 15:11:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3CA5320707 for ; Wed, 26 Aug 2020 15:11:17 +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="VAOKpGG4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3CA5320707 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 C383A8D0001; Wed, 26 Aug 2020 11:11:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC27C6B0075; Wed, 26 Aug 2020 11:11:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A632D8D0001; Wed, 26 Aug 2020 11:11:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8A3FC6B0007 for ; Wed, 26 Aug 2020 11:11:16 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 478544404 for ; Wed, 26 Aug 2020 15:11:16 +0000 (UTC) X-FDA: 77193058152.01.tail97_5c0a7af27065 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 01A2B1004CE26 for ; Wed, 26 Aug 2020 15:10:54 +0000 (UTC) X-HE-Tag: tail97_5c0a7af27065 X-Filterd-Recvd-Size: 4590 Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Wed, 26 Aug 2020 15:10:41 +0000 (UTC) Received: by mail-qt1-f193.google.com with SMTP id t23so1619036qto.3 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=k203QcCexbZZr4ZY1KGXY1Thqs1miEH8PDiWZT+9xDBERzoa3IAZUZ/G8APmxfImW3 dT20w6meN2qwOTPNDjvo1m8Plhooly+915Zk0z3j8HRGb8wSiQWfnzR/s3LE0jIK3WJ7 niBn3Q8P50YZhcKG5ZINqQuuRU3ty+LFRUAf8iypZdMkspRjV08WDz3huXltSyGpCWb+ uMKEXx8As/crST/vk+OUcEl1ICE4zt5U4Uw97XawBfIa0Me9Nk/KsC6XzMNqsetk6xV2 P29zzLipQtwt4X/aYDBCG6248LqCHL3o+6zt3Mkcyx7EX2swuQWJuDGYWPpSPrfdETlh I3Dg== X-Gm-Message-State: AOAM533yDt/nuIB7yZs5bFRB3tjQjfKQr/crO9kagPjYl6UI5+a+zCaG Q4/zJde6BEpsasnYoXuw1ShqIg== X-Google-Smtp-Source: ABdhPJyt5sPyNEvrEG8BF3rvteWdGY+/4wN0nkQCox0ECjk0O8GV0igfnvyvxHfWRXyOyeHkjwh8dw== 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> X-Rspamd-Queue-Id: 01A2B1004CE26 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 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? ]