| Message ID | 91586af267deb26b905fba61a9f1f665a204a4e3.1438331416.git.viresh.kumar@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 31-07-15, 17:32, yalin wang wrote: > > > On Jul 31, 2015, at 16:56, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > > > On Fri, Jul 31, 2015 at 02:08:34PM +0530, Viresh Kumar wrote: > >> IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there > >> is no need to do that again from its callers. Drop it. > >> > >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > > > Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > search in code, there are lots of using like this , does need add this check into checkpatch ? cc'd Joe for that. :) > # grep -r 'likely.*IS_ERR' . > ./include/linux/blk-cgroup.h: if (unlikely(IS_ERR(blkg))) > ./fs/nfs/objlayout/objio_osd.c: if (unlikely(IS_ERR(od))) { > ./fs/cifs/readdir.c: if (unlikely(IS_ERR(dentry))) > ./fs/ext4/extents.c: if (unlikely(IS_ERR(bh))) { > ./fs/ext4/extents.c: if (unlikely(IS_ERR(path1))) { > ./fs/ext4/extents.c: if (unlikely(IS_ERR(path2))) { Btw, my series has fixed all of them :)
On 31-07-15, 03:28, Joe Perches wrote:
> If it's all fixed, then it's unlikely to be needed in checkpatch.
I thought checkpatch is more about not committing new mistakes, rather than
finding them in old code.
On 31-07-15, 11:00, Joe Perches wrote: > On Fri, 2015-07-31 at 16:36 +0530, Viresh Kumar wrote: > > On 31-07-15, 03:28, Joe Perches wrote: > > > If it's all fixed, then it's unlikely to be needed in checkpatch. > > > > I thought checkpatch is more about not committing new mistakes, rather than > > finding them in old code. > > True, but checkpatch is more about style than substance. > > There are a lot of things that _could_ be added to the script > but don't have to be because of relative rarity. > > The unanswered fundamental though is whether the unlikely use > in #define IS_ERR_VALUE is useful. > > include/linux/err.h:21:#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO) > > How often does using unlikely here make the code smaller/faster > with more recent compilers than gcc 3.4? Or even using gcc 3.4. No idea :)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c index c107094f79ba..e14652480c59 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -149,7 +149,7 @@ static int start_stop_khugepaged(void) if (!khugepaged_thread) khugepaged_thread = kthread_run(khugepaged, NULL, "khugepaged"); - if (unlikely(IS_ERR(khugepaged_thread))) { + if (IS_ERR(khugepaged_thread)) { pr_err("khugepaged: kthread_run(khugepaged) failed\n"); err = PTR_ERR(khugepaged_thread); khugepaged_thread = NULL;
IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- mm/huge_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)