Re: [PATCH 1/1] Add config option for batched hcalls

2010-09-27 Thread Will Schmidt
On Sat, 2010-09-25 at 22:49 -0500, Olof Johansson wrote:
 On Fri, Sep 24, 2010 at 04:44:15PM -0500, Will Schmidt wrote:
  
  Add a config option for the (batched) MULTITCE and BULK_REMOVE h-calls.
  
  By default, these options are on and are beneficial for performance and
  throughput reasons.   If disabled, the code will fall back to using less
  optimal TCE and REMOVE hcalls.   The ability to easily disable these
  options is useful for some of the PREEMPT_RT related investigation and
  work occurring on Power.
 
 Hi,
 
 I can see why it's useful to enable and disable, but these are all
 runtime-checked, wouldn't it be more useful to add a bootarg to handle
 it instead of adding some new config options that pretty much everyone
 will always go with the defaults on?
 
 The bits are set early, but from looking at where they're used, there
 doesn't seem to be any harm in disabling them later on when a bootarg
 is convenient to parse and deal with?
 
 It has the benefit of easier on/off testing, if that has any value for
 production debug down the road.

Hi Olof, 
  Thats a good idea, let me poke at this a bit more, see if I can get
bootargs for this.  

Thanks, 
-Will

 
 
 -Olof
 


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/1] Add config option for batched hcalls

2010-09-25 Thread Olof Johansson
On Fri, Sep 24, 2010 at 04:44:15PM -0500, Will Schmidt wrote:
 
 Add a config option for the (batched) MULTITCE and BULK_REMOVE h-calls.
 
 By default, these options are on and are beneficial for performance and
 throughput reasons.   If disabled, the code will fall back to using less
 optimal TCE and REMOVE hcalls.   The ability to easily disable these
 options is useful for some of the PREEMPT_RT related investigation and
 work occurring on Power.

Hi,

I can see why it's useful to enable and disable, but these are all
runtime-checked, wouldn't it be more useful to add a bootarg to handle
it instead of adding some new config options that pretty much everyone
will always go with the defaults on?

The bits are set early, but from looking at where they're used, there
doesn't seem to be any harm in disabling them later on when a bootarg
is convenient to parse and deal with?

It has the benefit of easier on/off testing, if that has any value for
production debug down the road.


-Olof

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev