[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190725185800.GC30641@bombadil.infradead.org>
Date: Thu, 25 Jul 2019 11:58:00 -0700
From: Matthew Wilcox <willy@...radead.org>
To: Pengfei Li <lpf.vector@...il.com>
Cc: akpm@...ux-foundation.org, mgorman@...hsingularity.net,
mhocko@...e.com, vbabka@...e.cz, cai@....pw,
aryabinin@...tuozzo.com, osalvador@...e.de, rostedt@...dmis.org,
mingo@...hat.com, pavel.tatashin@...rosoft.com, rppt@...ux.ibm.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 01/10] mm/page_alloc: use unsigned int for "order" in
should_compact_retry()
On Fri, Jul 26, 2019 at 02:42:44AM +0800, Pengfei Li wrote:
> static inline bool
> -should_compact_retry(struct alloc_context *ac, int order, int alloc_flags,
> - enum compact_result compact_result,
> - enum compact_priority *compact_priority,
> - int *compaction_retries)
> +should_compact_retry(struct alloc_context *ac, unsigned int order,
> + int alloc_flags, enum compact_result compact_result,
> + enum compact_priority *compact_priority, int *compaction_retries)
> {
> int max_retries = MAX_COMPACT_RETRIES;
One tab here is insufficient indentation. It should be at least two.
Some parts of the kernel insist on lining up arguments with the opening
parenthesis of the function; I don't know if mm really obeys this rule,
but you're indenting function arguments to the same level as the opening
variables of the function, which is confusing.
Powered by blists - more mailing lists