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 DDACEC433EF for ; Wed, 12 Jan 2022 12:25:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65EE26B0154; Wed, 12 Jan 2022 07:25:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 60EAF6B0155; Wed, 12 Jan 2022 07:25:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D65C6B0156; Wed, 12 Jan 2022 07:25:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 3F1106B0154 for ; Wed, 12 Jan 2022 07:25:10 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E2EEA8E3EB for ; Wed, 12 Jan 2022 12:25:09 +0000 (UTC) X-FDA: 79021554738.24.D1262BF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 6172F160004 for ; Wed, 12 Jan 2022 12:25:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641990308; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xWgksL6bFpGhiY8GnHIJjFsUKx5kfO64Lt2XcltxSMk=; b=VU3pzOsZlSghR5YqTMTJ/hHs6a4HCKa0aHpYAvB5rGLEQia0H2LlkS6Citruw2fgDCI7// MOwpexEErT+9yUTwB6n2qn/Tv1sdfj7q/FvOW+fLEyp1v9nDJGwO/gSNYVG7tkQxfj8uBf XY9CjbmRbpZLyd7RcxQz6CVAsqp2WlE= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-557-hpS9Onz8N8-bZTFYrscaqQ-1; Wed, 12 Jan 2022 07:25:07 -0500 X-MC-Unique: hpS9Onz8N8-bZTFYrscaqQ-1 Received: by mail-ed1-f71.google.com with SMTP id ec25-20020a0564020d5900b003fc074c5d21so2069068edb.19 for ; Wed, 12 Jan 2022 04:25:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=xWgksL6bFpGhiY8GnHIJjFsUKx5kfO64Lt2XcltxSMk=; b=euh9Nj8sEr7oTyRunr9B4IVmvo62S9R1yET0raqmf0f32cLvtbY2acVgP05BxieYeg VqeoOEQmoIW0+d4fJUlIohZNv8wJc60tNnsZAa9OnPPZoAouqjNjMYGlYqJaXB0Pbf8r qFPM/zPIYS1FgJ1YPEJG2OXqe9V77HFX1Kv+3MLmr5H7He2zCX1AHGL6bfszqQpmh0wC uib7GENjvxg4z1z0e3oforHhOq1fIuoEgJYgruLEZvBmIHIc42MIF5HFey+buIEFE8xi usKXRvxRQ1ZkWzW9jkkXyGztJ2tuQAeGVgvXUJMHPAxjdiZvLGtsLXXN72BzitIOUWd4 zf3A== X-Gm-Message-State: AOAM531FXbXUPBa1aJ04k13p9kPOtJCAE0H167Q7S/AphHx+icmu5QjR ZlRS4NvVstn4BitzoJCegXDmp0cchUvY1BE8ntMfn1u8fP4Ty4RkTkRKwTF2P83jmgCiUKNXcmf JbITB9PnN/sI= X-Received: by 2002:a17:907:720f:: with SMTP id dr15mr7339375ejc.729.1641990306552; Wed, 12 Jan 2022 04:25:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJyqxWZY7TfzuBRT62moR2hjCiDFrckpFbnSxgt2c5ujzQ6k4qnDmvre7ffxzfYevGV/CcTIwg== X-Received: by 2002:a17:907:720f:: with SMTP id dr15mr7339357ejc.729.1641990306254; Wed, 12 Jan 2022 04:25:06 -0800 (PST) Received: from ?IPV6:2003:cb:c702:4700:e25f:39eb:3cb8:1dec? (p200300cbc7024700e25f39eb3cb81dec.dip0.t-ipconnect.de. [2003:cb:c702:4700:e25f:39eb:3cb8:1dec]) by smtp.gmail.com with ESMTPSA id gn36sm2897744ejc.29.2022.01.12.04.25.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jan 2022 04:25:05 -0800 (PST) Message-ID: Date: Wed, 12 Jan 2022 13:25:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: Minchan Kim , Andrew Morton Cc: Michal Hocko , linux-mm , LKML , Suren Baghdasaryan , John Dias , huww98@outlook.com, John Hubbard References: <20211228175904.3739751-1-minchan@kernel.org> From: David Hildenbrand Organization: Red Hat Subject: Re: [RFC v2] mm: introduce page pin owner In-Reply-To: <20211228175904.3739751-1-minchan@kernel.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6172F160004 X-Stat-Signature: 14xga1z6qy4gz45daefb6r933xk83aiz Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VU3pzOsZ; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf08.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam06 X-HE-Tag: 1641990309-743092 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 28.12.21 18: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. > It's worth noting that this is a pure debug feature, right? I like the general approach, however, IMHO the current naming is a bit sub-optimal and misleading. All you're doing is flagging pages that should result in a tracepoint when unref'ed. "page pinners" makes it somewhat sound like you're targeting FOLL_PIN, not simply any references. "owner" is misleading IMHO as well. What about something like: "mm: selective tracing of page reference holders on unref" PAGE_EXT_PIN_OWNER -> PAGE_EXT_TRACE_UNREF $whatever feature/user can then set the bit, for example, when migration fails. I somewhat dislike that it's implicitly activated by failed page migration. At least the current naming doesn't reflect that. > 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. I think I might be missing something. Aren't you simply reusing &page_ext->flags ? I mean, the "overhead" is just ordinary page_ext overhead ... and whee exactly are you changing "struct page" layout? Is this description outdated? > > 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). > I wonder if we could achieve the same thing for debugging by a) Tracing the PFN when migration fails b) Tracing any unref of any PFN User space can then combine both information to achieve the same result. I assume one would need a big trace buffer, but maybe for a debug feature good enough? -- Thanks, David / dhildenb