Can we undo the octeon hack?
    Warner Losh 
    imp at bsdimp.com
       
    Mon Jul 22 01:34:42 UTC 2013
    
    
  
I would too, but let's not gate a solution to this problem on that.
Warner
On Jul 21, 2013, at 3:29 PM, Juli Mallett wrote:
> I would really like a std.pci or something, too, so we don't have to
> enumerate all the PCI devices in every config.
> 
> On Sun, Jul 21, 2013 at 1:51 PM, Warner Losh <imp at bsdimp.com> wrote:
>> These should really be in the std.foo files for each specific subport. That way atheros could have one set, and octeon could have another.
>> 
>> I do know that we don't do the std.foo thing for the atheros config files, but we really should start, and this would be a good place to start...
>> 
>> Warner
>> 
>> On Jul 21, 2013, at 12:54 PM, Juli Mallett wrote:
>> 
>>> Making it possible to override each value would be ideal but
>>> cumbersome.  If you want to do that, by all means do!
>>> 
>>> Thanks,
>>> Juli.
>>> 
>>> On 2013-07-21, at 11:44, Adrian Chadd <adrian at freebsd.org> wrote:
>>> 
>>>> Hi Juli/Warner,
>>>> 
>>>> Is it possible to undo this particular hack, and allow these values to
>>>> be overridden in the kernel config files?
>>>> 
>>>> from kern.pre.mk
>>>> 
>>>> CFLAGS= ${COPTFLAGS} ${C_DIALECT} ${DEBUG} ${CWARNFLAGS}
>>>> CFLAGS+= ${INCLUDES} -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
>>>> opt_global.h
>>>> .if ${COMPILER_TYPE} != "clang"
>>>> CFLAGS+= -fno-common -finline-limit=${INLINE_LIMIT}
>>>> .if ${MACHINE_CPUARCH} != "mips"
>>>> CFLAGS+= --param inline-unit-growth=100
>>>> CFLAGS+= --param large-function-growth=1000
>>>> .else
>>>> # XXX Actually a gross hack just for Octeon because of the Simple Executive.
>>>> CFLAGS+= --param inline-unit-growth=10000
>>>> CFLAGS+= --param large-function-growth=100000
>>>> CFLAGS+= --param max-inline-insns-single=10000
>>>> .endif
>>>> .endif
>>>> 
>>>> I'd like to be able to experiment with different inline settings in
>>>> order to try and squeeze kernels down to be smaller.
>>>> 
>>>> Thanks!
>>>> 
>>>> 
>>>> -adrian
>> 
    
    
More information about the freebsd-mips
mailing list