From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 03:27:44 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 AE5F34E7 for ; Mon, 22 Jul 2013 03:27:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 836C71FE5 for ; Mon, 22 Jul 2013 03:27:44 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id q10so6350992pdj.10 for ; Sun, 21 Jul 2013 20:27:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=sKXxdwYCD+Vl/ZzMf/jeb8XZA6CTSabdMKtL60pNnSI=; b=U6SZDSoLXJOA9R/Y+2lb0qvWHCnLpghiIAyXBzwwlkht+tEsJZ1uugrqcN/gJASiIc r9OuNutjAYXM07qoiCs/weQj8eze/NepbUZUFG3S/xu8fnD0qOOfmMGPGJsJDo7ubeoT qZrD6z0Rs/fQyrsQobp50QUucS2gX4gDdWariCQUyXyfpEcPVrb2gBrIE8FMqhqb8I7x Um8JpokmQHbJaC8JDQuB5NeeFe7INxUlvwNRpBi+7AQQ+HuyD7Dv9I0Y1Q0vY6ah0N85 xKfSxJhOvpqDLjqnD/THzy8y1n3DFZ73D4UddRVnhGYQlYicjGP/fMubuMEZtJCdKsjT pQ4g== X-Received: by 10.68.255.1 with SMTP id am1mr28186127pbd.68.1374463159509; Sun, 21 Jul 2013 20:19:19 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id tr10sm33009148pbc.22.2013.07.21.20.19.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 20:19:18 -0700 (PDT) Sender: Warner Losh Subject: Re: Can we undo the octeon hack? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 21 Jul 2013 21:19:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <04C90F35-CDF1-437A-8867-9034689E46E9@bsdimp.com> References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> To: Juli Mallett X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlBo2+61dlI3/eYDVfupwH8cTsg1ATWfIzxnidJKvON0ui7DP0TlFRa3Y196kc2ng/Xmc9r 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:27:44 -0000 On Jul 21, 2013, at 9:00 PM, Juli Mallett wrote: > I know I shouldn't say this, but: How hard can it be? :P >=20 > In kern.pre.mk: >=20 > CFLAGS_PARAM_INLINE_UNIT_GROWTH?=3D100 > CFLAGS_PARAM_LARGE_FUNCTION_GROWTH?=3D1000 > CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE?=3D/* XXX what is default? */ > CFLAGS+=3D --param = inline-unit-growth=3D${CFLAGS_PARAM_INLINE_UNIT_GROWTH} > CFLAGS+=3D --param = large-function-growth=3D${CFLAGS_PARAM_LARGE_FUNCTION_GROWTH} > CFLAGS+=3D --param = max-inline-insns-single=3D${CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE} >=20 > And then in the Octeon config: >=20 > makeoptions CFLAGS_PARAM_INLINE_UNIT_GROWTH=3D10000 > makeoptions CFLAGS_PARAM_LARGE_FUNCTION_GROWTH=3D100000 > makeoptions CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE=3D10000 >=20 > Right? >=20 > Come up with a better name scheme, win 1/20 of 1 US cent. (Not > redeemable for cash.) >=20 > Most users will never see it; only Octeon needs such behaviour because > of how the Simple Executive is implemented. We're better off than I thought. We can put those in std.octeon1. Not sure I like having those names, but 1/20 of a cent isn't worth the = time it takes to type them... Warner > On Sun, Jul 21, 2013 at 7:56 PM, Adrian Chadd = wrote: >> .... ok, so, what's the game plan? :) >>=20 >>=20 >>=20 >> -adrian >>=20 >> 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. >>>=20 >>> 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. >>>>=20 >>>> Warner >>>>=20 >>>> On Jul 21, 2013, at 3:29 PM, Juli Mallett wrote: >>>>=20 >>>>> I would really like a std.pci or something, too, so we don't have = to >>>>> enumerate all the PCI devices in every config. >>>>>=20 >>>>> 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. >>>>>>=20 >>>>>> 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... >>>>>>=20 >>>>>> Warner >>>>>>=20 >>>>>> On Jul 21, 2013, at 12:54 PM, Juli Mallett wrote: >>>>>>=20 >>>>>>> Making it possible to override each value would be ideal but >>>>>>> cumbersome. If you want to do that, by all means do! >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Juli. >>>>>>>=20 >>>>>>> On 2013-07-21, at 11:44, Adrian Chadd = wrote: >>>>>>>=20 >>>>>>>> Hi Juli/Warner, >>>>>>>>=20 >>>>>>>> Is it possible to undo this particular hack, and allow these = values to >>>>>>>> be overridden in the kernel config files? >>>>>>>>=20 >>>>>>>> from kern.pre.mk >>>>>>>>=20 >>>>>>>> CFLAGS=3D ${COPTFLAGS} ${C_DIALECT} ${DEBUG} ${CWARNFLAGS} >>>>>>>> CFLAGS+=3D ${INCLUDES} -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS = -include >>>>>>>> opt_global.h >>>>>>>> .if ${COMPILER_TYPE} !=3D "clang" >>>>>>>> CFLAGS+=3D -fno-common -finline-limit=3D${INLINE_LIMIT} >>>>>>>> .if ${MACHINE_CPUARCH} !=3D "mips" >>>>>>>> CFLAGS+=3D --param inline-unit-growth=3D100 >>>>>>>> CFLAGS+=3D --param large-function-growth=3D1000 >>>>>>>> .else >>>>>>>> # XXX Actually a gross hack just for Octeon because of the = Simple Executive. >>>>>>>> CFLAGS+=3D --param inline-unit-growth=3D10000 >>>>>>>> CFLAGS+=3D --param large-function-growth=3D100000 >>>>>>>> CFLAGS+=3D --param max-inline-insns-single=3D10000 >>>>>>>> .endif >>>>>>>> .endif >>>>>>>>=20 >>>>>>>> I'd like to be able to experiment with different inline = settings in >>>>>>>> order to try and squeeze kernels down to be smaller. >>>>>>>>=20 >>>>>>>> Thanks! >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -adrian >>>>>>=20 >>>>=20