Re: [PATCHv3, RESEND 5/8] khugepaged: Allow to collapse a page shared across fork

From: John Hubbard <jhubbard@nvidia.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	<akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>, Zi Yan <ziy@nvidia.com>,
	Yang Shi <yang.shi@linux.alibaba.com>,
	Ralph Campbell <rcampbell@nvidia.com>,
	William Kucharski <william.kucharski@oracle.com>,
	<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv3, RESEND 5/8] khugepaged: Allow to collapse a page shared across fork
Date: Tue, 14 Apr 2020 19:42:39 -0700	[thread overview]
Message-ID: <ca114751-1a19-5b8a-5187-a0150716d3fa@nvidia.com> (raw)
In-Reply-To: <20200414213526.ecn3zcgnqxoveddq@box>

On 2020-04-14 14:35, Kirill A. Shutemov wrote:
> On Mon, Apr 13, 2020 at 01:48:22PM -0700, John Hubbard wrote:
> 
> [Thanks for all your suggestions and corrections]
> 
>>> +	if (IS_ENABLED(CONFIG_DEBUG_VM) && expected_refcount > refcount) {
>>> +		pr_err("expected_refcount: %d, refcount: %d\n",
>>> +				expected_refcount, refcount);
>>> +		dump_page(page, "Unexpected refcount");
>>
>>
>> I see two issues with the pr_err() and the dump_page() call:
>>
>> 1. You probably want to rate limit this, otherwise you'll have a big
>> problem if lots of pages are pinned!
> 
> Nope. Only if kernel is buggy. See below.
> 
>> 2. Actually, I don't think you'd want to print anything at all here, even with
>> rate limiting, because doing so presumes that "unexpected" means "wrong". And I
>> think this patch doesn't expect to have GUP pins (or pin_user_pages() pins, ha),
>> but that doesn't mean that they're wrong to have.
> 
> See condition. We only do it if refcount is *below* expected refcount. It
> should never happen. Pinned page would have refcount above expected.
> 

Yes, you are right. I misread the condition. This actually is just right. :)

thanks,
-- 
John Hubbard
NVIDIA