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 2D0BEC433EF for ; Wed, 12 Jan 2022 17:42:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 98FEA6B01B3; Wed, 12 Jan 2022 12:42:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 972276B01F0; Wed, 12 Jan 2022 12:42:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E0766B01F1; Wed, 12 Jan 2022 12:42:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id 5A7B26B01B3 for ; Wed, 12 Jan 2022 12:42:27 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id EB8B48249980 for ; Wed, 12 Jan 2022 17:42:26 +0000 (UTC) X-FDA: 79022354292.07.D6A57DE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf22.hostedemail.com (Postfix) with ESMTP id 67626C0011 for ; Wed, 12 Jan 2022 17:42:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1642009345; 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=vtoOALOKXJRZ0rX5JFYiDqkhpVXBYvGRnWcTrYRXWhI=; b=IyWuq9P2oaDAVlLOEIQqPoRnqKtNvRVQsSRs9eFPXrUh4gSImbM51AR6gHdtao9c5wprUD i5ivb/rE4E7qtOO9frJ6/C7KlG+DrpcB/CVXmVOged6kdR5RLxnR0BJlMe7ATeJk+ZZzve znTFIDMN1l0bIitJVJvzohyrbC4Z09g= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-564-1bzQ9Rw-OZ-PBgfxrxthzQ-1; Wed, 12 Jan 2022 12:42:24 -0500 X-MC-Unique: 1bzQ9Rw-OZ-PBgfxrxthzQ-1 Received: by mail-ed1-f70.google.com with SMTP id x11-20020aa7d38b000000b004004e4fc8fdso386445edq.6 for ; Wed, 12 Jan 2022 09:42:24 -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=vtoOALOKXJRZ0rX5JFYiDqkhpVXBYvGRnWcTrYRXWhI=; b=Eyq74aPz6hEBP8DiATSIVAavwTYJNzsQkKBojO5iAMLGKsz2ltSmQn3mx0gCvGpiuP yvyM/uytx4BYpX0lRNr2FMZL2EhSkNO41fuvGAwqhFc8BREt4KLQgRhqZbD7sVAZpSvj IHdVEPQJV/GC33sR4X+n9/xQD6t8YuTs1HUVfF+GiLXpiMHY+yKJEJkt3PYRL3RUvA8j 1DHoCek+Afv4O0rVTaRKqYrxJoli9KJnYicBslivNgSzd+WlBO5Qo19igCSiDQxPQLhI HPkQEFa/nCZA1kwTolbCn5qZJ9Z2AEClbYA7zq3dGu5UvJ+mgcWpLgs3YmS+wYPNQgMU UyGg== X-Gm-Message-State: AOAM533RPDfpKit2DteNkVdsfd48ClyOBlB4bdVwnGanSfzBhmY9nH0f sspUq5+bfziTGfNV5C3F4lPIpAC+r0EElJVQAYxjv+SUetmGn0Agy9Pd+LmjOWxbgi10J8ZjeVo KhxVkmKOiV4I= X-Received: by 2002:aa7:dc05:: with SMTP id b5mr697094edu.46.1642009343251; Wed, 12 Jan 2022 09:42:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJyZj1h2GRPhZ1kPWze0KLwP25d0Ho7SdKcyQhvf3yYfpe4HlkxujmDWMyAYxJR7kMykOONeww== X-Received: by 2002:aa7:dc05:: with SMTP id b5mr697075edu.46.1642009342989; Wed, 12 Jan 2022 09:42:22 -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 gt38sm120003ejc.114.2022.01.12.09.42.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jan 2022 09:42:22 -0800 (PST) Message-ID: Date: Wed, 12 Jan 2022 18:42:21 +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 Cc: Andrew Morton , 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: 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: 67626C0011 X-Stat-Signature: qhat63hrrw7wo1uibzd3hxgoy7b6rmy5 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IyWuq9P2; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf22.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam06 X-HE-Tag: 1642009346-160106 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: >> >> 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 couldn't imagine put_page tracking is generally useful except > migration failure. Do you have reasonable usecase in your mind > to make the feature general to be used? HWpoison etc. purposes maybe? Trace who still held a reference a page that was poisoned and couldn't be removed? Or in general, tracking references to something that should have a refcount of 0 because it should have been freed, but for some reason there are still references around? > Otherwise, I'd like to have feature naming more higher level > to represent page migration failure and then tracking unref of > the page. In the sense, PagePinOwner John suggested was good > candidate(Even, my original naming PagePinner was worse) since Personally, I dislike both variants. > I was trouble to abstract the feature with short word. > If we approach "what feature is doing" rather than "what's > the feature's goal"(I feel the your suggestion would be close > to what feature is doing), I'd like to express "unreference on > migraiton failed page" so PAGE_EXT_UNMIGRATED_UNREF > (However, I prefer the feature naming more "what we want to achieve") > E.g., PAGE_EXT_TRACE_UNREF will trace unref to the page once the bit is set. The functionality itself is completely independent of migration failures. That's just the code that sets it to enable the underlying tracing for that specific page. >> >> 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 feature enables page_ext which adds up 8 bytes per 4KB and on every > put operation, it need to access the additional flag on page_ext which > affects performance since page_put is the common operation. > Yeah, the struct size stuff in the wording is rather misleading. > Let me change the workding something like this: > > 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 checking additional flag on > every put_page opeartion. I'd adjust to As this feature depends on page_ext->flags, it will consume an additional 8 bytes per 4KB page to enable page_ext if not already enabled. ... > >> >>> >>> 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? > > I definitely tried it for cma allocation failure but it generated > enormous output(Please keep it in mind that we also need stacktrace) > due to too frequent put_page and compaction operation(Even, I filter > them out to track only cma pages but it was still huge since the CMA > size is 1/8 of the system). Even though I increased the buffer size > a lot, the buffer was easily overwritten. Moreover, even though it's > debug feature, we need to release the feature into dogfooder to catch > the real problem in the field so consuming too much memory as well as > backtrace operhead on every put page are tough to be used in field. Makes sense, I was expecting the output to be large, but possible it's going to be way too large. Would it also make sense to track for a flagged page new taken references, such that you can differentiate between new (e.g., temporary) ones and previous ones? Feels like a reasonable addition. -- Thanks, David / dhildenb