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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 14E61C433E0 for ; Thu, 2 Jul 2020 16:19:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D530820720 for ; Thu, 2 Jul 2020 16:19:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D530820720 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 506906B00EE; Thu, 2 Jul 2020 12:19:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B6AA8D0012; Thu, 2 Jul 2020 12:19:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CD556B00F0; Thu, 2 Jul 2020 12:19:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 22F306B00EE for ; Thu, 2 Jul 2020 12:19:12 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A248D8245571 for ; Thu, 2 Jul 2020 16:19:11 +0000 (UTC) X-FDA: 76993645302.28.rake26_020658626e8a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 6CA376C16 for ; Thu, 2 Jul 2020 16:19:11 +0000 (UTC) X-HE-Tag: rake26_020658626e8a X-Filterd-Recvd-Size: 3582 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Thu, 2 Jul 2020 16:19:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9593FAEB2; Thu, 2 Jul 2020 16:19:09 +0000 (UTC) Subject: Re: [PATCH 1/3] mm: Print head flags in dump_page To: "Kirill A. Shutemov" Cc: Matthew Wilcox , John Hubbard , linux-mm@kvack.org, Andrew Morton , "Kirill A. Shutemov" , Mike Kravetz References: <20200629151918.15537-1-willy@infradead.org> <20200629151918.15537-2-willy@infradead.org> <20200629225134.GL25523@casper.infradead.org> <29baf5ca-1187-e00a-ee5c-5f08f7b69683@nvidia.com> <49e5da43-88bd-bac5-4dcc-5f5abb0d9a1b@suse.cz> <20200630115950.GM25523@casper.infradead.org> <20200702155336.san26vjcasbnbswy@box> From: Vlastimil Babka Message-ID: Date: Thu, 2 Jul 2020 18:19:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200702155336.san26vjcasbnbswy@box> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6CA376C16 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 7/2/20 5:53 PM, Kirill A. Shutemov wrote: > On Thu, Jul 02, 2020 at 04:59:14PM +0200, Vlastimil Babka wrote: >> On 6/30/20 1:59 PM, Matthew Wilcox wrote: >> > On Tue, Jun 30, 2020 at 10:02:50AM +0200, Vlastimil Babka wrote: >> >> I would also prefer this approach.It would be also nice to know the tail index. >> >> As long as page pointer wasn't hashed, it was possible to figure this out, but >> >> now it's not. Maybe print pfn of both page and head? >> > >> >> On 6/30/20 1:35 AM, John Hubbard wrote: >> >> > ...so with that fix, along with your line break approach in the other thread, >> >> > a tail page dump of a FOLL_PIN page looks like this: >> >> > >> >> > [ 38.027987] page:00000000abaef9ae refcount:513 mapcount:1 mapping:0000000000000000 index:0x11 >> > >> > index is the last thing printed on this line. If it's something like >> > index:0x12345678, you can reduce it mod 1<> > line. >> >> Hmm, I guess that works as long as head pages really have index aligned to 1 << >> order ... they should, right? >> >> But does it fail for HugeTLB? CC Kirill (git blamed) and Mike. >> page_to_pgoff() has for PageHeadHuge this: >> return page->index << compound_order(page) >> >> but page_to_index() does simply >> pgoff = compound_head(page)->index; >> pgoff += page - compound_head(page); >> >> Shouldn't it also do a < > PageHeadHuge() is only true for head pages, so we are fine here. Really? We are calculatting index (pgoff) of tail page, which should be index of head page plus n for n'th tail page; the unit is base pages. But ff HugeTLB head pages use the unit of huge page in page->index, and page_to_pgoff() translates it to unit of base pages, then we should do the same when calculating the index of tail page, no? Otherwise we are adding up units of huge pages (from head->index) with units of base page (n'th tail) and get garbage as a result, AFAICS?