Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1500631 > unrolled thread

Re: [RFC v2 PATCH] mm/percpu.c: simplify grouping CPU algorithm

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC v2 PATCH] mm/percpu.c: simplify grouping CPU algorithm Tejun Heo <tj@kernel.org> - 2016-10-14 01:40 +0200
    Re: [RFC v2 PATCH] mm/percpu.c: simplify grouping CPU algorithm zijun_hu <zijun_hu@zoho.com> - 2016-10-14 02:00 +0200
      Re: [RFC v2 PATCH] mm/percpu.c: simplify grouping CPU algorithm Tejun Heo <tj@kernel.org> - 2016-10-14 02:40 +0200
        Re: [RFC v2 PATCH] mm/percpu.c: simplify grouping CPU algorithm zijun_hu <zijun_hu@zoho.com> - 2016-10-14 03:20 +0200

#1500631 — Re: [RFC v2 PATCH] mm/percpu.c: simplify grouping CPU algorithm

Hello, Zijun.

On Tue, Oct 11, 2016 at 08:48:45PM +0800, zijun_hu wrote:
> compared with the original algorithm theoretically and practically, the
> new one educes the same grouping results, besides, it is more effective,
> simpler and easier to understand.

If the original code wasn't broken and the new code produces the same
output, I'd really not mess with this code.  There simply is no upside
to messing with this code.  It's run once during boot and never a
noticeable contributor of boot overhead.  Maybe the new code is a bit
simpler and more efficient but the actual benefit is so small that any
risk would outweigh it.

Thanks.

-- 
tejun

[toc] | [next] | [standalone]

#1500637

On 2016/10/14 7:37, Tejun Heo wrote:
> Hello, Zijun.
> 
> On Tue, Oct 11, 2016 at 08:48:45PM +0800, zijun_hu wrote:
>> compared with the original algorithm theoretically and practically, the
>> new one educes the same grouping results, besides, it is more effective,
>> simpler and easier to understand.
> 
> If the original code wasn't broken and the new code produces the same
> output, I'd really not mess with this code.  There simply is no upside
> to messing with this code.  It's run once during boot and never a
> noticeable contributor of boot overhead.  Maybe the new code is a bit
> simpler and more efficient but the actual benefit is so small that any
> risk would outweigh it.
> 
> Thanks.
>
the main intent of this change is making the CPU grouping algorithm more
easily to understand, especially, for newcomer for memory managements
take me as a example, i really take me a longer timer to understand it
 

[toc] | [prev] | [next] | [standalone]

#1500647

Hello,

On Fri, Oct 14, 2016 at 07:49:44AM +0800, zijun_hu wrote:
> the main intent of this change is making the CPU grouping algorithm more
> easily to understand, especially, for newcomer for memory managements
> take me as a example, i really take me a longer timer to understand it

If the new code is easier to understand, it's only so marginally.  It
just isn't worth the effort or risk.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1500661

On 2016/10/14 8:33, Tejun Heo wrote:
> Hello,
> 
> On Fri, Oct 14, 2016 at 07:49:44AM +0800, zijun_hu wrote:
>> the main intent of this change is making the CPU grouping algorithm more
>> easily to understand, especially, for newcomer for memory managements
>> take me as a example, i really take me a longer timer to understand it
> 
> If the new code is easier to understand, it's only so marginally.  It
> just isn't worth the effort or risk.
> 
> Thanks.
> 
okay i agree with your opinion.
but i am sure this changes don't have any risk after tests and theoretic analyse

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web