From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 03:12:43 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 075E039E for ; Mon, 22 Jul 2013 03:12:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C87A71F76 for ; Mon, 22 Jul 2013 03:12:42 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id c10so13743049ieb.24 for ; Sun, 21 Jul 2013 20:12:42 -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=5AImM2etAH6TMntsT3b9xY207y368RGPEaOoJvBJ1XU=; b=avOOGFNzxe1TN7ho67oXASXpoSubCPRSABGK3V1lOYLrBXecmJT90j0lH6RfXplu7M CBLeq0E+dn4zHY08926kCp6Fic2rSxydx9JlUkBwDaB9HUqHYmkHqZFpJrcogfzLbR4R u177XzlIJFxVcYtnzNdqnTAD44HAHoDAmyKZEZ4+6VDKIPqlSglDlvaLfmVMElvKc7q+ MkC6YKRfT+i0+NztkocVRWuVYZABsPDuUdeH8LGaIQnm1qOQB2YjocH5ODhXZa6sGzjh Z2rX20gq3MRWktklrtLohMWRnJp3xeiN+W3++pwMFOKNr4/rpAlaUrk3Kt4ChUB0HoJI 1Qtg== X-Received: by 10.50.60.2 with SMTP id d2mr8611137igr.52.1374462761904; Sun, 21 Jul 2013 20:12:41 -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 hj6sm12653938igb.1.2013.07.21.20.12.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 20:12:40 -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:12:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <793CB840-40AF-487E-99A0-2C34FF17FD11@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: ALoCoQnRV/TMxi1Schjymh8N9csihVb7uHbdx6SvbvynMes4MjqvUJ2gnkctppASbR/Y24ow5wC/ 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:12:43 -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 How hard do you want it to be? > 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? Other than being completely wrong, this looks good... :) > 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. Except we'd need it in every octeon config file :( 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