From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 04:30:37 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 710CABCE for ; Mon, 22 Jul 2013 04:30:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E66A215C for ; Mon, 22 Jul 2013 04:30:36 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id e11so14522148iej.29 for ; Sun, 21 Jul 2013 21:30:36 -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=8jhAQHWbS41ugE8C2F3v5LB9ha5bHWCDQHy0p2sCoUo=; b=DJaUQkq/H8dKo3NEwFfY07M4PlkCr8HSd/aeG5fiiqwimMP08Io6jRzjoVRvGqve0T hvEu/655bgtHrrvsEE0d5/lR93blNCIkE2QRhtpNy1DrsGldSdvfIP2257blgEm5uQLa lzRVMY6GwnHo8m0bMwxSD42lBxxJe3Un+WmbDkcV7JiuL3xLcZxRA656f6M9oQtVj6GD L5JQx7vcT5TnrxQq7NB1QXVddMdZHvsHJaRlVOYaorCw2UAx24wkOqRgdZc6mZPJFS8P I0PUS1qLdjK82w6eU2Kq+CkwO9uf5miHuiAXTWilVLat/88asNeQsuJ7pKlRcwKwXgMP nqPg== X-Received: by 10.50.225.66 with SMTP id ri2mr8716662igc.55.1374467436064; Sun, 21 Jul 2013 21:30:36 -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 w5sm55014183igz.10.2013.07.21.21.30.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 21:30:35 -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 22:30:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <61CE43B9-02F6-45BF-B96A-65498DD61756@bsdimp.com> References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> <04C90F35-CDF1-437A-8867-9034689E46E9@bsdimp.com> To: Juli Mallett X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQngE5XpfS+HGZbqk2Zpri3yjkXosqZCN7thn+lpx3yMLXWP82ttbkHgNQK4PuDnvYIN2sqD 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 04:30:37 -0000 Yea, the only ugliness I see is that this gets pulled into the kernel = modules as well... But there the limits are smaller (and fixed for all = architectures)... Otherwise, I have most of a patch together that I'll post after a few = kernels build. Warner On Jul 21, 2013, at 9:21 PM, Juli Mallett wrote: > On Sun, Jul 21, 2013 at 8:19 PM, Warner Losh wrote: >>=20 >> On Jul 21, 2013, at 9:00 PM, Juli Mallett wrote: >>=20 >>> 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. >>=20 >> We're better off than I thought. We can put those in std.octeon1. >>=20 >> Not sure I like having those names, but 1/20 of a cent isn't worth = the time it takes to type them... >=20 > Long names discourage Gentooish funroll-loopsing! It's a feature! > These are not user-serviceable parts. Hell, even I can't really > service this stuff effectively. Having to set them at all is a bug.