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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11001C433F5 for ; Thu, 6 Jan 2022 23:24:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BC356B0071; Thu, 6 Jan 2022 18:24:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 76AD96B0073; Thu, 6 Jan 2022 18:24:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6330B6B0074; Thu, 6 Jan 2022 18:24:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 4D2866B0071 for ; Thu, 6 Jan 2022 18:24:21 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0736F18037C6F for ; Thu, 6 Jan 2022 23:24:21 +0000 (UTC) X-FDA: 79001443122.16.4FD70FD Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf31.hostedemail.com (Postfix) with ESMTP id 252D52000A for ; Thu, 6 Jan 2022 23:24:19 +0000 (UTC) Received: by mail-pf1-f169.google.com with SMTP id v11so3753901pfu.2 for ; Thu, 06 Jan 2022 15:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=OGz+KTMNaQJ31AH4jyNlIzitAxhmTUfwOup337ea6Eo=; b=cAYrjwHAhyUVWaSD9ze5qUSKTz4/MkkKhrEflwSvkyFNCwjtpW7o0tLw31wwBiX3tX SogtFxbF2pTg0GBKeGTlXNeTGeUcMspymNRNsU76qtDDCQ0BXkBXMT3cmSYEtLQ3qTiy 7pnfu+cwPEQFtV09x+YgZKTB2CJCOITfsDzHVCihk4ACGYsi5wOBzXPLpm+njs8vf6F1 rs2RO/Dy6gQ6IenOQi4NxJ4Jxg8/gI4JdLaayBrwMlv7WHujmhMZwrC4aNvyfMN5aDBg czHxH13bEXod7OqxL3RnzRoZ6aOSR87zjMyelxXQxnyqxOBxjuQSKvpDMxGZxfXqPzNU 9m5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=OGz+KTMNaQJ31AH4jyNlIzitAxhmTUfwOup337ea6Eo=; b=7PLD/weSVQwIJ1EeCbmAnnDu+F7InENntRbI/N++iwmDrqnSzfS8LvNnBLF3nK63/8 eDe/E6YumMh5RLhXgdrjjbNkuAz60yJaobcObHMa74+4JZhylhcp1UVQu0o+T1mBGB85 Dz5wEc3UMMYmsjGLwwD5kYtCarOpRz40e5t+adgSNAKDVSFRYCdJFjKvRw4yNKNfc2lT tcXL2TBVhoAY4nnsEgwAnbUH3ClYV8ANaSJ8tsUY4r1EJxk+hYT8XLVPx2tCDxHPTqDV qfyLvUeOQDIGffkG1uNB9OQT5ixgz4m9xz0GN3tIU269fCKyt8ap1BA9ABRrsyIR7ycR GxUw== X-Gm-Message-State: AOAM530i/lsvdoGbslszcVrtyTO4F1G2sFzVaM1u0LxQ+S722TZyyhXA zgakMQIUoumfAPAeZK+tBnw= X-Google-Smtp-Source: ABdhPJxD9O0dnp9kdv3hMwibX0/0xyQlA+s7c/q46/kx9Na07Z83MCqm5ccvoAWFGThBRtuRgjlnow== X-Received: by 2002:a63:4554:: with SMTP id u20mr54315435pgk.463.1641511459629; Thu, 06 Jan 2022 15:24:19 -0800 (PST) Received: from google.com ([2620:15c:211:201:e32:b92d:27fe:aa55]) by smtp.gmail.com with ESMTPSA id nu14sm3784167pjb.17.2022.01.06.15.24.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Jan 2022 15:24:19 -0800 (PST) Date: Thu, 6 Jan 2022 15:24:17 -0800 From: Minchan Kim To: John Hubbard Cc: Andrew Morton , Michal Hocko , David Hildenbrand , linux-mm , LKML , Suren Baghdasaryan , John Dias , huww98@outlook.com Subject: Re: [RFC v2] mm: introduce page pin owner Message-ID: References: <20211228175904.3739751-1-minchan@kernel.org> <978452be-6377-69e3-4720-520410d32b31@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <978452be-6377-69e3-4720-520410d32b31@nvidia.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 252D52000A X-Stat-Signature: tuhmwf3yw87gnh6nakwn4fr43ecnc3da Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cAYrjwHA; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf31.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com X-HE-Tag: 1641511459-313001 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 Thu, Jan 06, 2022 at 02:27:48PM -0800, John Hubbard wrote: > On 12/28/21 09:59, Minchan Kim wrote: > > A Contiguous Memory Allocator(CMA) allocation can fail if any page > > within the requested range has an elevated refcount(a pinned page). > > > > Debugging such failures is difficult, because the struct pages only > > show a combined refcount, and do not show the callstacks or > > backtraces of the code that acquired each refcount. So the source > > of the page pins remains a mystery, at the time of CMA failure. > > > > In order to solve this without adding too much overhead, just do > > nothing most of the time, which is pretty low overhead. However, > > once a CMA failure occurs, then mark the page (this requires a > > pointer's worth of space in struct page, but it uses page extensions > > to get that), and start tracing the subsequent put_page() calls. > > As the program finishes up, each page pin will be undone, and > > traced with a backtrace. The programmer reads the trace output and > > sees the list of all page pinning code paths. > > > > This will consume an additional 8 bytes per 4KB page, or an > > additional 0.2% of RAM. In addition to the storage space, it will > > have some performance cost, due to increasing the size of struct > > page so that it is greater than the cacheline size (or multiples > > thereof) of popular (x86, ...) CPUs. > > > > The idea can apply every user of migrate_pages as well as CMA to > > know the reason why the page migration failed. To support it, > > the implementation takes "enum migrate_reason" string as filter > > of the tracepoint(see below). > > > > Hi Minchan, > > If this is ready to propose, then maybe it's time to remove the "RFC" > qualification from the subject line, and re-post for final review. > > And also when you do that, could you please specify which tree or commit > this applies to? I wasn't able to figure that out this time. Sorry for that. It was based on next-20211224. > > > Usage) > > This extensive "usage" section is probably helpful, but the commit > log is certainly not the place for the "how to" documentation. Let's > find an .rst file to stash it in, I think. I wanted to get some review for implementation/interface/usage before respin removing the RFC. Otherwise, the the documentation need to keep update heavily. Based on your comment, I think you are almost agree with as-is. Then, yeah, let me cook up the doc and repost it with removing the RFC tag. Thanks.