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.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_2 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 CEBFCECE58A for ; Tue, 1 Oct 2019 13:18:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9482C2190F for ; Tue, 1 Oct 2019 13:18:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="lGp6SqYW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9482C2190F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1245A8E0005; Tue, 1 Oct 2019 09:18:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D6718E0001; Tue, 1 Oct 2019 09:18:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F06B98E0005; Tue, 1 Oct 2019 09:18:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0113.hostedemail.com [216.40.44.113]) by kanga.kvack.org (Postfix) with ESMTP id D13A68E0001 for ; Tue, 1 Oct 2019 09:18:14 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 8AE7268BE for ; Tue, 1 Oct 2019 13:18:14 +0000 (UTC) X-FDA: 75995269308.18.rings08_821cbd1891b1b X-HE-Tag: rings08_821cbd1891b1b X-Filterd-Recvd-Size: 5352 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Tue, 1 Oct 2019 13:18:13 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id z67so11106998qkb.12 for ; Tue, 01 Oct 2019 06:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=wjg5ezOc5p7km8S342IaUr3A38UGT2t2Rxceh2nlfUU=; b=lGp6SqYWxT9IFi+KGl1pHet+QbGKnv9h5fRA3tHQiPKK22pU5UvC0p7Tkp/LVSzNfB oh1GwarLvZcJfIFf6WzcDjApRPlIssJyX5fkvJ1K9zOPCv5gLlb6d4yOko9bEAKYxyny LUTciaMHBRbhSOJM0SLdXM82rrvJArFZnVVVzr+cywYp+Z7dud/o1KtefHReI/KLzX0X R+u2n/TS/gaiuZzcJy2anjMIQFf3IZ3m25aY6O0Fs6tbc+tlCzLm+XhcIQ1y1FDjZcg5 bC7kfuyLqGzcpAfPFJrfP90cKr3almQWWlDHDEbn74QfhONlhED3nBcasTNfSxhcm+41 ri0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=wjg5ezOc5p7km8S342IaUr3A38UGT2t2Rxceh2nlfUU=; b=KcQtd8rDNnFuq8+/oA0348Oq59TcCvtnPm06JRtGV6egoUGXxVD+8O7o6xh8ir6/79 j86hck0n3d5jMOOHGshNW3MDb9wKG/Fd6J8sVRAzgz1ccrgG9HapBrQu3XF67StiV8qV W9GNo2YnnBEsqRSi1ggLV7Po4vnImEtM5Qta89RKQC1jz8P4gfwLaczgCq6+7S4PTikF yTqFuIPvJ7pUw8Iid9co9FJOINt7JRSJSXmbtjglbNsn6rmcd7G0PZM+9RK6tPtidlbr 0iEhlncxm8jX48CJHvKReVmu3Vf32l4OQYcJg3oN9uU/YD/G0yKIG6MIR1tGDr3ThW6T 75Xg== X-Gm-Message-State: APjAAAWduL6muyRUkDvzeIA76qbg6TIC3BToTGrsuIobi0udECAxgXCH fkcwmaAsXw2BIw0IsDE0owS8rdjwlig= X-Google-Smtp-Source: APXvYqyNL9IyO0vyZzASB134qH8CPv466017882cxvJNuyos/hOCFC9v49BtrPBHXe4sgaMMLsantg== X-Received: by 2002:a37:4286:: with SMTP id p128mr6108139qka.40.1569935893364; Tue, 01 Oct 2019 06:18:13 -0700 (PDT) Received: from dhcp-41-57.bos.redhat.com (nat-pool-bos-t.redhat.com. [66.187.233.206]) by smtp.gmail.com with ESMTPSA id a190sm8443634qkf.118.2019.10.01.06.18.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Oct 2019 06:18:12 -0700 (PDT) Message-ID: <1569935890.5576.255.camel@lca.pw> Subject: Re: [PATCH v2 2/3] mm, page_owner: decouple freeing stack trace from debug_pagealloc From: Qian Cai To: Vlastimil Babka , "Kirill A. Shutemov" Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, "Kirill A. Shutemov" , Matthew Wilcox , Mel Gorman , Michal Hocko , Dmitry Vyukov , Walter Wu , Andrey Ryabinin Date: Tue, 01 Oct 2019 09:18:10 -0400 In-Reply-To: References: <731C4866-DF28-4C96-8EEE-5F22359501FE@lca.pw> <218f6fa7-a91e-4630-12ea-52abb6762d55@suse.cz> <20191001115114.gnala74q3ydreuii@box> <1569932788.5576.247.camel@lca.pw> <626cd04e-513c-a50b-6787-d79690964088@suse.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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, 2019-10-01 at 14:35 +0200, Vlastimil Babka wrote: > On 10/1/19 2:32 PM, Vlastimil Babka wrote: > > On 10/1/19 2:26 PM, Qian Cai wrote: > > > On Tue, 2019-10-01 at 14:51 +0300, Kirill A. Shutemov wrote: > > > > On Tue, Oct 01, 2019 at 10:07:44AM +0200, Vlastimil Babka wrote: > > > > > On 10/1/19 1:49 AM, Qian Cai wrote: > > > > > > > > DEBUG_PAGEALLOC is much more intrusive debug option. Not all architectures > > > > support it in an efficient way. Some require hibernation. > > > > > > > > I don't see a reason to tie these two option together. > > > > > > Make sense. How about page_owner=on will have page_owner_free=on by default? > > > That way we don't need the extra parameter. > > > > > > There were others that didn't want that overhead (memory+cpu) always. So the > > last version is as flexible as we can get, IMHO, before approaching bikeshed > > territory. It's just another parameter. > > Or suggest how to replace page_owner=on with something else (page_owner=full?) > and I can change that. But I don't want to implement a variant where we store only > the freeing stack, though. I don't know why you think it is a variant. It sounds to me it is a natural extension that belongs to page_owner=on that it could always store freeing stack to help with debugging. Then, it could make implementation easier without all those different combinations you mentioned in the patch description that could confuse anyone. If someone complains about the overhead introduced to the existing page_owner=on users, then I think we should have some number to prove that say how much overhead there by storing freeing stack in page_owner=on, 10%, 50%?