[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201409231955.FDB73406.FOOJLOVQMHFSFt@I-love.SAKURA.ne.jp>
Date: Tue, 23 Sep 2014 19:55:48 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: lizefan@...wei.com, tj@...nel.org
Cc: peterz@...radead.org, mingo@...nel.org, miaox@...fujitsu.com,
linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
keescook@...omium.org
Subject: Re: [PATCH v2 3/3] cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should beatomic flags
Zefan Li wrote:
> Tetsuo reported a hard-to-reproduce kernel crash on RHEL6, which happend
s/happend/happened/
> @@ -1972,6 +1973,14 @@ static inline void memalloc_noio_restore(unsigned int flags)
> TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
> TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)
>
> +TASK_PFA_TEST(SPREAD_PAGE, spread_page)
> +TASK_PFA_SET(SPREAD_PAGE, spread_page)
> +TASK_PFA_CLEAR(SPREAD_PAGE, spread_page)
> +
> +TASK_PFA_TEST(SPREAD_SLAB, spread_slab)
> +TASK_PFA_SET(SPREAD_SLAB, spread_slab)
> +TASK_PFA_CLEAR(SPREAD_SLAB, spread_slab)
> +
I wonder how adding 3 macro lines differs from 3 inlined functions.
Personally, from LXR (source code browser) point of view, inlined functions
are more friendly than macros. Also, I wonder about the cost of extracting
macros in a file which is likely included by every file but referenced
by few files. Speak of SPREAD_PAGE and SPREAD_SLAB, they should be defined
as inlined functions in include/linux/cpuset.h rather than as macros in
include/linux/sched.h ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists