[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patches] powerpc 8xx dcbz problem
- To: Nathan Sidwell <nathan@xxxxxxxxxxxxxxxx>
- Subject: Re: [patches] powerpc 8xx dcbz problem
- From: Steven Munroe <munroesj@xxxxxxxxxx>
- Date: Tue, 05 Jun 2007 12:28:36 -0500
Nathan Sidwell wrote:
> Steven Munroe wrote:
>> Nathan Sidwell wrote:
>>> Steven Munroe wrote:
>>>
>>>> add the --with-cpu support as a way to manage this. You all might be
>>>> very annoyed with me, if I had
>>>> 970/power4/power5/power5+/power6/power6x
>>>> specific code cluttering up performance sensitive common code!
>>> This patch is not cluttering up performance sensitive common code.
>>> memset already has a check for whether the cache line size is zero.
>>> Please don't construct straw men :)
>>>
>> Memset is performance sensitive code and the dynamic __cache_line_size
>> check is slowing down 970/power4/power5/power5+/power6/power6x. When the
>> processor can retire (up to) 5 instructions per cycle, the dependent
>> sequence to address the GOT and check the __cache_line_size is very
>> noticable.
>
> Can you please explain how the patch (modified to not clone
> __cache_line_size to __memset_cache_line_size, but just set it to
> zero), would cause a performance problem. We're talking about adding
> a one time check to the code path that sets __cache_line_size.
>
> We're not altering the memset implementation that already has such
> checks in it, nor are we altering targets that are implementing their
> own memset.
>
I am trying to explain the larger context. That inserting dynamic test
alter over the place is in general a bad idea.
So yes the one time check in libc-start.c does not hurt your situation.
The dynamic __cache_line_size hurts my situation by its very existience.
So please don't assume that you can add dynamic tuning anywhere you want
or anytime you want. Becuase while you may solve your problem you will
invariable harm someone elses situation.