From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 03:01:02 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8A230EF8 for ; Mon, 22 Jul 2013 03:01:02 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 125671E1F for ; Mon, 22 Jul 2013 03:01:01 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id 10so4781262lbf.8 for ; Sun, 21 Jul 2013 20:00:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=3g2W/qCrkk33kGC7s9mmqysARdnz4788TJuql6R/5bw=; b=lfrEMfptay7NTJcNBxwjInMIkxVai9zFxp/QWQcEr1UyEN+HZCzbBZ553oC1BtqFID orPygClGkPZqgdG1U73rPhkWJLNuePCBdzJ3+zYQGrbRwJgukNNV6LIEX9TAbLIH2ZxD kBbDcDEjgZf/nxIuGPo42rTNYme8WgZ1EWRuZ+7mMeFOFa+CXr2Rv6oqpKwlqUhlOOsR DROSQvqfZOFuQ3uiVhTj9tgs+ba3ZCk3iOoMXxG7kaH+szrce9SBveVzgtd/3QoWisWC yccX5DXXZj6irxxUbjN/1pW7OifX8/gRKFwbHvvZD+/W4o1sIRTN/3w2i3xAVBBo2IqW z0cw== X-Received: by 10.152.20.165 with SMTP id o5mr11536495lae.71.1374462053702; Sun, 21 Jul 2013 20:00:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.231 with HTTP; Sun, 21 Jul 2013 20:00:33 -0700 (PDT) In-Reply-To: References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> From: Juli Mallett Date: Sun, 21 Jul 2013 20:00:33 -0700 Message-ID: Subject: Re: Can we undo the octeon hack? To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmFsjRGTZ/rAqhOhh0IF8nK/OvoBoTT2KinPuk2ElxrgS+ojY8G5WJJsXtRM3NdQ64jXokw Cc: Warner Losh , "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:01:02 -0000 I know I shouldn't say this, but: How hard can it be? :P In kern.pre.mk: CFLAGS_PARAM_INLINE_UNIT_GROWTH?=100 CFLAGS_PARAM_LARGE_FUNCTION_GROWTH?=1000 CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE?=/* XXX what is default? */ CFLAGS+= --param inline-unit-growth=${CFLAGS_PARAM_INLINE_UNIT_GROWTH} CFLAGS+= --param large-function-growth=${CFLAGS_PARAM_LARGE_FUNCTION_GROWTH} CFLAGS+= --param max-inline-insns-single=${CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE} And then in the Octeon config: makeoptions CFLAGS_PARAM_INLINE_UNIT_GROWTH=10000 makeoptions CFLAGS_PARAM_LARGE_FUNCTION_GROWTH=100000 makeoptions CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE=10000 Right? Come up with a better name scheme, win 1/20 of 1 US cent. (Not redeemable for cash.) Most users will never see it; only Octeon needs such behaviour because of how the Simple Executive is implemented. On Sun, Jul 21, 2013 at 7:56 PM, Adrian Chadd wrote: > .... ok, so, what's the game plan? :) > > > > -adrian > > On 21 July 2013 18:47, Juli Mallett wrote: >> Do you think we should gate moving this singular hack to the Octeon >> config file on breaking out a bunch of std.foo files now? :) I was >> just saying that if you're advocating doing that work, we should do >> some more generalized stuff, too. Like, std.pcidriversandwhatnot >> should be machine-independent and would reduce a lot of maintenance >> between architectures, that kind of thing. I don't think any of it >> should gate moving INLINE_CFLAG_SOMETHING_FOO_WHATEVER_BISCUIT_* into >> the Octeon kernel config and out of sys/conf. >> >> On Sun, Jul 21, 2013 at 6:34 PM, Warner Losh wrote: >>> 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 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 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 >>>>> >>>