[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3c7c722d-e8d0-f52b-e0ea-7994bd6b55bb@linux.alibaba.com>
Date: Wed, 11 Jan 2023 14:40:20 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: Matthew Wilcox <willy@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] mm: compaction: Remove redundant VM_BUG_ON() in
compact_zone()
On 1/11/2023 7:37 AM, Matthew Wilcox wrote:
> On Tue, Jan 10, 2023 at 03:25:32PM -0800, Andrew Morton wrote:
>> On Tue, 10 Jan 2023 13:37:57 +0000 Matthew Wilcox <willy@...radead.org> wrote:
>>
>>> On Tue, Jan 10, 2023 at 09:36:18PM +0800, Baolin Wang wrote:
>>>> The compaction_suitable() will never return values other than COMPACT_SUCCESS,
>>>> COMPACT_SKIPPED and COMPACT_CONTINUE, so after validation of COMPACT_SUCCESS
>>>> and COMPACT_SKIPPED, we will never hit other unexpected case. Thus remove
>>>> the redundant VM_BUG_ON() validation for the return values of compaction_suitable().
>>>
>>> I don't understand why we'd remove this check.
>>
>> Well, just from code inspection it serves no purpose.
>>
>> Such an assertion might be useful during early code development, but I
>> think we can consider compaction_suitable() to adequately debugged by
>> now?
>
> What if compaction_suitable() is modified to return another value?
Then this will be an expected value which should be handled by caller,
and IMO we can not make such assumption for future to keep this
unhelpful check.
Powered by blists - more mailing lists