From owner-freebsd-mips@FreeBSD.ORG Sun Jul 21 18:42:24 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 319AF123; Sun, 21 Jul 2013 18:42:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5D8CDB; Sun, 21 Jul 2013 18:42:23 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ey16so1176649wid.4 for ; Sun, 21 Jul 2013 11:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=gvEo9R1FYNTezaMP6/i/HNBCRFqut7EFcb0InalTpH4=; b=fIjlLYWhp/C2+hCBaPNHck2jgoCiQ8Y8P3NjpiOBrhZBTinbn685zEiKWReUvc/7xH iizNIlV7ECZbUyJtPEPylurLHb1f5Y+Y8bDVpIwyY3AFSNFJGlQtTtA6vpkEmFRapMkc ug74gUaXEkyUKx7/S71mqkL2mrRc/3WvU6MQ+XRawy54W8cSsm1PC2Y5RZHIoi354lXo mQF3s1vbZK6Y2SGJs/b8rbbQuu++01YBBr6uI5Nu+kP1p84LuhKf8WRBkzfd38GL5VQ+ AzGJQu4rpQVzGYuzcN8AMnstW8/ZAUDG9hyR5qck8qtw5oZbiC97iVWa7mnrf1LZwozu /l1g== MIME-Version: 1.0 X-Received: by 10.180.185.148 with SMTP id fc20mr16628538wic.0.1374432142860; Sun, 21 Jul 2013 11:42:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 21 Jul 2013 11:42:22 -0700 (PDT) Date: Sun, 21 Jul 2013 11:42:22 -0700 X-Google-Sender-Auth: VAgu6KUL3xs6DlCZun0z8LBNGC8 Message-ID: Subject: Enabling clang/llvm for MIPS? From: Adrian Chadd To: freebsd-mips@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 21 Jul 2013 18:42:24 -0000 Hiya, I'd like to start doing test builds of the mips stuff (specifically mips4kc, mips24k and mips74k) on freebsd-head with clang/llvm. What changes are needed to the makefile framework to enable this? Thanks, -Adrian From owner-freebsd-mips@FreeBSD.ORG Sun Jul 21 18:44:33 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 9DFF027B; Sun, 21 Jul 2013 18:44:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by mx1.freebsd.org (Postfix) with ESMTP id E29E4D00; Sun, 21 Jul 2013 18:44:32 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id e11so5346552wgh.30 for ; Sun, 21 Jul 2013 11:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Eb13jf3sz1Uoi9eXNJ4ulRrUlCUd/3fpJDIrSVmEkS0=; b=0tkK/ikDzVWV0yFxyxXi4liriC5DAaMT3Zh7vo7mLA6jh/QplHrIlEQYtXO+KebbsO W8Tt4x/pehRHx9IK7O+p89wNjpBIryGRr+DS+R4kadlhT0Kd84gR31+wI1NCtAkroxQa 93wbeZjGkbVj0IMLoQ3nY8s239Vgyhp3LVJleY2fMDZ5YnTHzDnoTyiuSykfKWXPytjy icRXCvG1/hxpZRDVCEjetFpVEzusi9cEVGDPO8VeUFwfjtkNSe0Dj9sxnqZGnU1jQ33U DHZlrmVKoNDHeMaujJMdBLi3mUWFuTSLDKX88eWsgjKELwztPhLcF1Llu1yslFE1VihZ aedQ== MIME-Version: 1.0 X-Received: by 10.180.82.196 with SMTP id k4mr27998801wiy.0.1374432272124; Sun, 21 Jul 2013 11:44:32 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 21 Jul 2013 11:44:32 -0700 (PDT) Date: Sun, 21 Jul 2013 11:44:32 -0700 X-Google-Sender-Auth: bLHUKXR_nX8sMtjtUKplT3JA42g Message-ID: Subject: Can we undo the octeon hack? From: Adrian Chadd To: freebsd-mips@freebsd.org, Warner Losh , Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 21 Jul 2013 18:44:33 -0000 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 From owner-freebsd-mips@FreeBSD.ORG Sun Jul 21 18:54:49 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 A9BEC4F3 for ; Sun, 21 Jul 2013 18:54:49 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 35802D6D for ; Sun, 21 Jul 2013 18:54:48 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id ec20so4741073lab.27 for ; Sun, 21 Jul 2013 11:54:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=9vQyyera4xxWW1AfEg9xRmL/R48ENhl8ELFDkUVVyLM=; b=Nm8a5chf/kCK2vcuSF913W3lTujNcNuY1rp28ncuPgzizlvoy9rpRLefJfTg9bVSON Bz/bZsKpvH5jlJo/er18mahK/hi4XMQS4D3DjLT1Z1PG1OjdqI0VzvkNdMxEvtCbJAgf jn8oeP5XVyBo2z/aAzhh5XujgISCSVSFmdOQBAJRvbHWyXkUTUHsj0O21/JMoA9uMFW9 SNG+n21ThFW54gtmt3FuImB4+bwtxFcGnThUU1h7WeDjlGra9AGl/Wq/oIzMY+n2wXJB ZTVO1R27NFdMHGA1Kaep96orBKWOuH8A8OlrMyBQZFOeixlfkoLTGTr6oBCJ2wb2gvHW JzSQ== X-Received: by 10.112.97.132 with SMTP id ea4mr10723027lbb.80.1374432882369; Sun, 21 Jul 2013 11:54:42 -0700 (PDT) References: From: Juli Mallett Mime-Version: 1.0 (1.0) In-Reply-To: Date: Sun, 21 Jul 2013 11:54:36 -0700 Message-ID: <6401792509903023722@unknownmsgid> Subject: Re: Can we undo the octeon hack? To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmFWxFQ5mIlkIyWRJb6gMymz+1vlnAYmSei9kO3uv4BVIemk1XDnqlRm8A5NdjfVJdq3Hln 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: Sun, 21 Jul 2013 18:54:49 -0000 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 From owner-freebsd-mips@FreeBSD.ORG Sun Jul 21 20:05:07 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 1CFBAEF2; Sun, 21 Jul 2013 20:05:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id D67AEFDF; Sun, 21 Jul 2013 20:05:06 +0000 (UTC) Received: from [192.168.1.106] (249-086-128-083.dynamic.caiway.nl [83.128.86.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 560235C5A; Sun, 21 Jul 2013 22:04:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Enabling clang/llvm for MIPS? From: Dimitry Andric In-Reply-To: Date: Sun, 21 Jul 2013 22:04:55 +0200 Content-Transfer-Encoding: 7bit Message-Id: <333C8EE2-1ADC-41EE-A474-9CE12B6E11EA@FreeBSD.org> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1508) Cc: freebsd-current@freebsd.org, 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: Sun, 21 Jul 2013 20:05:07 -0000 On Jul 21, 2013, at 20:42, Adrian Chadd wrote: > I'd like to start doing test builds of the mips stuff (specifically > mips4kc, mips24k and mips74k) on freebsd-head with clang/llvm. > > What changes are needed to the makefile framework to enable this? In share/mk/bsd.own.mk, modify these parts: # Clang is only for x86, powerpc and little-endian arm right now, by default. .if ${__T} == "amd64" || ${__T} == "i386" || ${__T:Mpowerpc*} __DEFAULT_YES_OPTIONS+=CLANG CLANG_FULL .elif ${__T} == "arm" || ${__T} == "armv6" __DEFAULT_YES_OPTIONS+=CLANG # GCC is unable to build the full clang on arm, disable it by default. __DEFAULT_NO_OPTIONS+=CLANG_FULL .else __DEFAULT_NO_OPTIONS+=CLANG CLANG_FULL .endif # Clang the default system compiler only on little-endian arm and x86. .if ${__T} == "amd64" || ${__T} == "arm" || ${__T} == "armv6" || \ ${__T} == "i386" __DEFAULT_YES_OPTIONS+=CLANG_IS_CC .else __DEFAULT_NO_OPTIONS+=CLANG_IS_CC .endif The first part enables building clang, the second makes it the default compiler. I take it you only want the first one for now? -Dimitry From owner-freebsd-mips@FreeBSD.ORG Sun Jul 21 21:12:44 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 8C73BD94 for ; Sun, 21 Jul 2013 21:12:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx1.freebsd.org (Postfix) with ESMTP id 65FFF32F for ; Sun, 21 Jul 2013 21:12:44 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id fa1so965326pad.33 for ; Sun, 21 Jul 2013 14:12:43 -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=Tx6hGYUu44lAldF2HaRJr5CPdS3/U/h5pnJkqDZ1yXQ=; b=giziIARpakeINcqHXSGlvTLhzKWbyOrnSuGcqsM/ZAcjf52navvFw6S4lCGJGh/0mF p1BxYiSZsTEGCsr5mXBmB1VvMHphLcAaOJ7bplJUpso2IxjZhQp0AlmDYYg5Fu4/3tvS dbGWuy5waGWB7vLMBIN5OiSL475puzVIeQ6Duruo+c5NhOvrXw50Ryon8c/IkhGaNEnH FZY2eToekZ5h+X68aXTnpGf3xCugamGtsoBVdMsWMMopD7j2WG1uYaqotaWVQVwbq3s4 jFKeSmbPioxJ2C/5VSsO6teAWLuGljH3ghm+ifRe5O10a5vnSlicjrHGd7KBdRpHehy6 s2Zw== X-Received: by 10.66.139.227 with SMTP id rb3mr28634909pab.121.1374440807672; Sun, 21 Jul 2013 14:06:47 -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 ss8sm15852544pab.6.2013.07.21.14.06.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 14:06:46 -0700 (PDT) Sender: Warner Losh Subject: Re: Enabling clang/llvm for MIPS? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <333C8EE2-1ADC-41EE-A474-9CE12B6E11EA@FreeBSD.org> Date: Sun, 21 Jul 2013 15:06:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <685512EE-BEB7-4D42-95D1-AC0454C90AB9@bsdimp.com> References: <333C8EE2-1ADC-41EE-A474-9CE12B6E11EA@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkalWZvuByAjs2Ef6b//LmkfNUNlaFriv4Onaz4U90621lp4kiE3mGikNY17XMBoU5CNR16 Cc: freebsd-current@freebsd.org, 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: Sun, 21 Jul 2013 21:12:44 -0000 On Jul 21, 2013, at 2:04 PM, Dimitry Andric wrote: >=20 > On Jul 21, 2013, at 20:42, Adrian Chadd wrote: >> I'd like to start doing test builds of the mips stuff (specifically >> mips4kc, mips24k and mips74k) on freebsd-head with clang/llvm. >>=20 >> What changes are needed to the makefile framework to enable this? >=20 > In share/mk/bsd.own.mk, modify these parts: >=20 > # Clang is only for x86, powerpc and little-endian arm right now, by = default. > .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "i386" || ${__T:Mpowerpc*} > __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_FULL > .elif ${__T} =3D=3D "arm" || ${__T} =3D=3D "armv6" > __DEFAULT_YES_OPTIONS+=3DCLANG > # GCC is unable to build the full clang on arm, disable it by default. > __DEFAULT_NO_OPTIONS+=3DCLANG_FULL > .else > __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_FULL > .endif > # Clang the default system compiler only on little-endian arm and x86. > .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "arm" || ${__T} =3D=3D = "armv6" || \ > ${__T} =3D=3D "i386" > __DEFAULT_YES_OPTIONS+=3DCLANG_IS_CC > .else > __DEFAULT_NO_OPTIONS+=3DCLANG_IS_CC > .endif >=20 > The first part enables building clang, the second makes it the default > compiler. I take it you only want the first one for now? make buildworld WITH_CLANG=3Dt WITHOUT_CLANG_FULL=3Dt = WITHOUT_CLANG_IS_CC=3Dt Warner= From owner-freebsd-mips@FreeBSD.ORG Sun Jul 21 21:21:25 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 ABE9DDF9 for ; Sun, 21 Jul 2013 21:21:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7C63A354 for ; Sun, 21 Jul 2013 21:21:25 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id 9so13489483iec.5 for ; Sun, 21 Jul 2013 14:21:19 -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=nYoA+Pob1rNl55pdb+QNRFUUm2t/0M2+cBs7JY9eLvA=; b=RA58bTrhtS18ydYZno/jkJ/YlSqwbfeD+pEFKdD/5CAFB3ozJBubV2fxqpakJkZ8cy jjXus4K4nlgULEPPZI6/wCaKznyWNwm26MenBOqFQQqwtNtECBGg6JE8QtwcWD3P7Oyc 5VCfdLy4zVEupHxWoOFoB473ILiVAFo7SlHXsDsjfc5IVklF2evq/evpbiaouq3meI4t MY7tx2Td6kzcIPIAqz88JOr1yDD2LBQpoGjPww+4Xt9gn36ybh08/UtqetTJQHqEOrBJ uExniG/gxeqxtig/3v4Dm73HubUmDTowsU+LH1aIYQMCFkyglSIfMlLTzX5OSr3f7WZo Zqzw== X-Received: by 10.43.63.17 with SMTP id xc17mr16010828icb.75.1374439889872; Sun, 21 Jul 2013 13:51:29 -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 w5sm52709247igz.10.2013.07.21.13.51.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 13:51:28 -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: <6401792509903023722@unknownmsgid> Date: Sun, 21 Jul 2013 14:51:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6401792509903023722@unknownmsgid> To: Juli Mallett X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQleS1Z64bbUdtMtnTq4p1fgkpwPUCBYXv/r66reGxyWmjYh+1cjhpEC/dcWA6VOc9Wzk/ZY 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: Sun, 21 Jul 2013 21:21:25 -0000 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! >=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 From owner-freebsd-mips@FreeBSD.ORG Sun Jul 21 21:29:38 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 80725E5D for ; Sun, 21 Jul 2013 21:29:38 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0D0375 for ; Sun, 21 Jul 2013 21:29:37 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id hi8so1964070lab.33 for ; Sun, 21 Jul 2013 14:29:31 -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=2za8TwYHTDQUB7jtyfDgMeiVdUMoMH7/wXsYKuPDDaE=; b=cleKAagfqA5mmQxzWsgI3QHcDQ+Y74EwZCUp9gSbBOgQSfV/DQrj8y950VOdmwumOL MgA4Z+xtFc/dJIX3n3mqZsG1H2XPsdtynL+5BeYcnz3WHpRfKzV6EKeAcVqB41ltmXFF rty2AuVCRXXS4PltIxyZpkYmabGJS8z1KtQJMRh4LmzhC43pHrEdbEHP/klzJrRUe0hb rd0FDMzz6nlzMApqY6AkTgP2dF9KDwKfJ3b8rQDTU9YBRT1VG2jRZUwwYqHnb6Pghjpy BTYx+V/PTIcv8YA4S4RGOUk9H+gP3jQi8ZiAT8f/DYebPQsS2Q1wudnLcvTAe6L71o1O ovGA== X-Received: by 10.112.97.132 with SMTP id ea4mr10884212lbb.80.1374442170988; Sun, 21 Jul 2013 14:29:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.231 with HTTP; Sun, 21 Jul 2013 14:29:10 -0700 (PDT) In-Reply-To: References: <6401792509903023722@unknownmsgid> From: Juli Mallett Date: Sun, 21 Jul 2013 14:29:10 -0700 Message-ID: Subject: Re: Can we undo the octeon hack? To: Warner Losh Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn5SnL9qcy/tv8Spdsl1354/tSKJdf85lefm+F/O94dNlBaE2fvgP4mk22hHHPsSggut0WH 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: Sun, 21 Jul 2013 21:29:38 -0000 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 > From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 01:34:42 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 4FAA897F for ; Mon, 22 Jul 2013 01:34:42 +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 203EF1BFD for ; Mon, 22 Jul 2013 01:34:41 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id c10so13595371ieb.24 for ; Sun, 21 Jul 2013 18:34:41 -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=8fy6K/UGQj+2f2IhTamfb/f9udxV9RExtU3eRc7qTB4=; b=gWFSXr/sHWuql6EDQ5ShoLzF++as/lAMda0O5JvZv9Fu27In790xxNjYjAtZvKRlQk RH4hibMu7ECtTPa4u6s3CaNPevmCyCGv6rCFRml51qX9DGMmD4r2OXSQ0RJUv58Fc22j YkfsgzwO/ebJeNs7Z77dEErilF6x1TM87Z4fkmapHq7FsywWxSKinH2eIU40BGf4FcSl wlc+ocYfT1mZFDSjSSz0HyhJp6VMuhBoZgisSwwjCfzY+UO1fF01PgAr+HzcCbeLyIDM nRo46zN5c9SIzcHV3/HAMvstignKLHGgP3d68fpiY/KyFocE4RIkgo3QnXQU9dXaFuRl Prpg== X-Received: by 10.43.139.133 with SMTP id iw5mr16333259icc.0.1374456880946; Sun, 21 Jul 2013 18:34:40 -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 hj6sm12147406igb.1.2013.07.21.18.34.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 18:34: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 19:34:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> References: <6401792509903023722@unknownmsgid> To: Juli Mallett X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQknAELoW7fP4tZlQJ7qJHQtghv5JleB4TXDbzL4DSWBjUsPe8dQW1H5RGCPwFv2IOtFZpBq 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 01:34:42 -0000 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. >=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 From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 01:54:06 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 1A692C1A for ; Mon, 22 Jul 2013 01:54:06 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 956AD1C6B for ; Mon, 22 Jul 2013 01:54:05 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id x10so4868586lbi.19 for ; Sun, 21 Jul 2013 18:53:57 -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=ELMx0uZmqEwNoxarW9IlpVRLkCUgTli1YlSoHwy8AIc=; b=UHokSKX+K4eL/aD4qP4aAvA+VnB546z1aVSN6pU395NvBGVUfG+xNIePxVADjYD6m0 +f8kfpLK0TIGPuinNMKoV3tf9BfqMOX2R7NetjmIox0vOCMX9NnFKI+YHFJDfo4mVHbx 4B6Ii3JrHAjnUyMgwHXpo9E14GV1Xz05ZqFLGOXDlKACSPK6N22b1I58ORCXV7toGRn4 3VGJFx2oIDpg8bSod8K1ZWu0qgtZOv2mPWUnNjmaHM/2UfNMpk8/e22c4DCXVA5WzgxY ZKx8I5m6LGiNn0aGJQkrR/4XEyOo+x9naPJm5EtxP4BMN+hQpWgKcYonokZVwNRyovLq 50Hw== X-Received: by 10.112.97.132 with SMTP id ea4mr11114546lbb.80.1374457662055; Sun, 21 Jul 2013 18:47:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.231 with HTTP; Sun, 21 Jul 2013 18:47:22 -0700 (PDT) In-Reply-To: <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> From: Juli Mallett Date: Sun, 21 Jul 2013 18:47:22 -0700 Message-ID: Subject: Re: Can we undo the octeon hack? To: Warner Losh Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm185fDCK5gbuG0qhLRcVoLAANPElmAjLav5xMyW1yawByd55KpDR/XxLH+1Gj0u7DmFywZ 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 01:54:06 -0000 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 >>> > From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 02:56:05 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 E67EAB68; Mon, 22 Jul 2013 02:56:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 513341DD6; Mon, 22 Jul 2013 02:56:05 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so1374387wib.8 for ; Sun, 21 Jul 2013 19:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=30mazOPZxmBWxytDBm1niTtfnPsUoCWvOOgl3m97lYI=; b=AXNlExSSKx9Reg776vZik4/H/Q5dp9urMJ2uHoFSavbr1uDN6JZbKixVLTQMNEIeMN WBGv80Y7GbgtUAhFDnBSg6yXDufsHBZPCDW83fT9lEmmmG9fJ8M6r/PjiiwoeR/hh6Y5 gg7sGh2ghy22mPO14qe7pq7jnQSBhsnKZN6ucJpKUGX2nRi/GcTqn0zzAkzGejQuiAhf fsIXX5sBCl3iuqpAjUCrdSI8qp3Wm4Ak2+bNf8TnE4xMhiAdofuqnu2NzaQH4FmAx1zZ pEAxJ3SIVy/zEgGegUxkgWquMlJJtRIxNO7ODbwnk4/xRu2f5NZUkIr9GxhDjBakBk44 lQ6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=30mazOPZxmBWxytDBm1niTtfnPsUoCWvOOgl3m97lYI=; b=bshjw4+K+Doyaf+z70VDRMrVOyUYEvbJ84BYQzX8j40EZihGbgpzucjAHbKiVlIizP s5tW6G7n58tGanOPJ7m4lYZ/RXaZf0vftPoCfmAj5Mu5Gyx5nQTADR4/8I4f+kNrznT9 TVJ5oZcUMQDS8GlZDrAEX+0EF4ThFwU5x3VxmhciaN60mAHOGhWu/Q+QBZNVrappQZMt R+jJiyfJaZj7WjC+6Co1Csyw5B4n7sM6H/72R/Js/PhUjTWja2G3A14wWtT2CoTmfyQP 1I77A+MLKvb3WYDCEhlQvP8w8CHA4WugzCVUQ1/szYS8lEmJKBedvy3ae/Cay1EIfy5M THLA== MIME-Version: 1.0 X-Received: by 10.180.11.6 with SMTP id m6mr4306279wib.0.1374461763646; Sun, 21 Jul 2013 19:56:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 21 Jul 2013 19:56:03 -0700 (PDT) In-Reply-To: References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> Date: Sun, 21 Jul 2013 19:56:03 -0700 X-Google-Sender-Auth: K4h3VUETsyQGqiM8sG0ZD9m7sps Message-ID: Subject: Re: Can we undo the octeon hack? From: Adrian Chadd To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 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 02:56:06 -0000 .... 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 >>>> >> 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 >>>>> >>> 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 From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 03:21:42 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 940A342B for ; Mon, 22 Jul 2013 03:21:42 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19AD71FAF for ; Mon, 22 Jul 2013 03:21:41 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id d10so4910196lbj.0 for ; Sun, 21 Jul 2013 20:21:33 -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=HWdZhPQ94PWTHjXEUEjp1ajGqllnLljBToTb4lZzZQE=; b=dvhx1yZV1hh5A+CyWbMrYDSXWC7KC5QszCEOoCcZ3pum86BoTYLD9cHwIiyJdKvseO n+fj+169n3xMbRlw6Www//XlWqlr80wVkSwICDlLbBkFaRtkxTtqlLQQ7iODtSRi79sJ 6xwAumBQTDwr9J6B4PsaejvBjwH2OReu/DrRDarKNu/X3t56W//Qg8/ZHZjgI8X01RBh 3Y9b0C8dSRcdfrKEpScoSRoe6PuUeAkUweGY+7eNDczNSc2O7PaCPf65hwVKeKABO54l KjgLvbWSLrm4XBHfOpV4qgwrWyHe1AKdqw8bYfiw2RhECtFyS9Uvp0T1C7j1RKmH1ynp 6UCw== X-Received: by 10.112.61.199 with SMTP id s7mr11379997lbr.53.1374463293685; Sun, 21 Jul 2013 20:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.231 with HTTP; Sun, 21 Jul 2013 20:21:13 -0700 (PDT) In-Reply-To: <04C90F35-CDF1-437A-8867-9034689E46E9@bsdimp.com> References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> <04C90F35-CDF1-437A-8867-9034689E46E9@bsdimp.com> From: Juli Mallett Date: Sun, 21 Jul 2013 20:21:13 -0700 Message-ID: Subject: Re: Can we undo the octeon hack? To: Warner Losh Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkHk2enCnoLk3e+l/KIPxxt1EUj4dlVoBmf7zjs1wR/Fcg4Z9KcS1BQMIG8Lr/m3sDOFDYT 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:21:42 -0000 On Sun, Jul 21, 2013 at 8:19 PM, Warner Losh wrote: > > 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 >> >> 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. > > 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... 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. From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 03:27:24 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 9101249D for ; Mon, 22 Jul 2013 03:27:24 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 17D341FDC for ; Mon, 22 Jul 2013 03:27:23 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id ga9so3132782lab.10 for ; Sun, 21 Jul 2013 20:27:15 -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=Muyk+qe3soN03L1IGivyZUzCujGytF71vlemjLMePI4=; b=VfKia065rULkOK6GhePmDGIkcQpNng2XaX0X2fxcBn9GXRGM9XOhGWWudrpRrc/8Zs 8NNvv29ah+FYVfywFAKwqIax1axthBRCbkN9SRCFzSXldqmHMeaBFIFMiANqzgZNlyr9 kWiMlZ3oE8lVM22MREQHZbHz3M3St6tJ5zIkW0JfE7St7uytasm8RWNSVJtnxmez0TT7 t0rubgH2ZVQuLgQdnd7STqiV1khKgcqW6/ASSisUwDxQRu4KKw+6/78LO6/hlfSxGTwR 5XVzBsZW46VGgC7PE4VdFQMIlAGrTKOwtg3LKuX2jCPLSWVnJxyegPa4JEDj2as8+hnv yiYQ== X-Received: by 10.152.2.201 with SMTP id 9mr11316386law.84.1374463136707; Sun, 21 Jul 2013 20:18:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.113.231 with HTTP; Sun, 21 Jul 2013 20:18:36 -0700 (PDT) In-Reply-To: <793CB840-40AF-487E-99A0-2C34FF17FD11@bsdimp.com> References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> <793CB840-40AF-487E-99A0-2C34FF17FD11@bsdimp.com> From: Juli Mallett Date: Sun, 21 Jul 2013 20:18:36 -0700 Message-ID: Subject: Re: Can we undo the octeon hack? To: Warner Losh Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk3gp18w6yBOC/qq9bEl9ImyJQDTJ5fFLvdPirMuiDprZ3EeW9uHS0HxaJRQyzA2PB0Sc46 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:24 -0000 On Sun, Jul 21, 2013 at 8:12 PM, Warner Losh wrote: > > 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: >> >> 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? > > 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.) >> >> 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 :( We have a lot of stuff we need in every Octeon config file already, I don't see this as making that worse. std.octeon or whatever it's called would be fine, too. I just don't care for the NetBSD-ish std.* system and don't make much use of it myself, but it seems reasonable to put it there, since one already exists. Oh, wait, that's misnamed "std.octeon1" so let's refuse to do anything about that, too? :P From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 03:27:29 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 3AD934A0 for ; Mon, 22 Jul 2013 03:27:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 07C301FDE for ; Mon, 22 Jul 2013 03:27:28 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id 9so14076326iec.19 for ; Sun, 21 Jul 2013 20:27:28 -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=GXnMAHU4jiHL9fMj3IPxv8OqqKTpQeZoQ6iXIuUDZUY=; b=CnrIYIgMtbyJNRRMt6Ap0o094kZ5dlybN3LOvcrREtHtV31yGJ7dSh3lCVqnqNaPoq N/gLFjg11BGQCvBp055TNy565xO4VHoz4zwzS1VdMr/+AiYvhw8pD1pYJ5NRwJUx/Zok a2U/Ri8KWcYyYnDy4/bLouZQ0r8w3mNwe1B7bgIQNcC3bGCpOQKi0/nmQYdTkhwn3cLD PbhIxClkRAJrN9sMP0aQ/2S8izbSqqjQ8FD1a4l0Nih8WfT3TW3xOabJSOaO1RvJ7JvQ 8+pLcRhPZqxL54ReoKML0VTKKlszdsvhxoSCO8XH26nq0YWXzQFMZPEhRK9q9tt2NnlP 2ZLA== X-Received: by 10.43.141.206 with SMTP id jf14mr16638649icc.8.1374463648180; Sun, 21 Jul 2013 20:27:28 -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 w5sm54699185igz.10.2013.07.21.20.27.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 20:27:27 -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:27:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <83EA6D99-9B5F-400A-BC79-BE4D16255A84@bsdimp.com> References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> <793CB840-40AF-487E-99A0-2C34FF17FD11@bsdimp.com> To: Juli Mallett X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnD6Jx9Ng0OsqzJHt09Su3sw8KhakecxZp4/IKQZ4Idwya+ZSg1SAB94KwlMU7J4btF0xHp 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:29 -0000 On Jul 21, 2013, at 9:18 PM, Juli Mallett wrote: > On Sun, Jul 21, 2013 at 8:12 PM, Warner Losh wrote: >>=20 >> 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 >> How hard do you want it to be? >>=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 >> Other than being completely wrong, this looks good... :) >>=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 >> Except we'd need it in every octeon config file :( >=20 > We have a lot of stuff we need in every Octeon config file already, I > don't see this as making that worse. std.octeon or whatever it's > called would be fine, too. I just don't care for the NetBSD-ish std.* > system and don't make much use of it myself, but it seems reasonable > to put it there, since one already exists. Oh, wait, that's misnamed > "std.octeon1" so let's refuse to do anything about that, too? :P I used to hate the std.foo stuff, but after putting nearly all the SoC = specific glue for dozens of different SoCs over on the ARM side in them, = I began to see its wisdom... Warner= 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 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. From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 11:06:47 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 E43C6457 for ; Mon, 22 Jul 2013 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D487924A0 for ; Mon, 22 Jul 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6MB6l5J053752 for ; Mon, 22 Jul 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6MB6lvH053750 for freebsd-mips@FreeBSD.org; Mon, 22 Jul 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Jul 2013 11:06:47 GMT Message-Id: <201307221106.r6MB6lvH053750@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-mips@FreeBSD.org Subject: Current problem reports assigned to 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 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/178319 mips [patch] [arge] arge_stop() doesn't clean the tx ring p o kern/178318 mips [patch] [arge] if_arge/bootp race under some circunsta o kern/177876 mips [mips] kernel stack overflow panic on mips64, EdgeRout o kern/177832 mips [mips] [gpio] [patch] GPIO and RF LED do not function o kern/177032 mips [arge] arge1 fails to attach on UBNT Routerstation o kern/165951 mips [ar913x] [ath] DDR flush isn't being done for the WMAC p kern/163670 mips [mips][arge] arge can't allocate ring buffer on multip 7 problems total. From owner-freebsd-mips@FreeBSD.ORG Fri Jul 26 12:24:26 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0DDB5D4D for ; Fri, 26 Jul 2013 12:24:26 +0000 (UTC) (envelope-from nbounce-653-48846-53449958-00d4c-58c652a7@kiccall.eu) Received: from m3.kiccall.eu (m3.kiccall.eu [88.198.82.167]) by mx1.freebsd.org (Postfix) with ESMTP id A306E2615 for ; Fri, 26 Jul 2013 12:24:25 +0000 (UTC) Received: from list653 (m3.kiccall.eu [88.198.82.167]) by m3.kiccall.eu (Postfix) with ESMTP id 65E4621C6568 for ; Fri, 26 Jul 2013 14:19:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=kiccall.eu; s=default; t=1374841173; bh=Nq8SYJIowc09Y3zJym1w8fi2alU=; h=Content-Type:MIME-Version:From:Sender:Message-Id:List-Unsubscribe: Subject:To:Date; b=Nzw1WAdMr3urtONXbAYy/2fUFR3u7deLOe8SYuZcKID5+mCg18jIC0iJkBeDgbR1x S4n+g/TnliqXS1shdndh592iaTMqQLd+mfDaDK6zgJ7UtHgxzEvoC1VGTiLvW0Hg3s n/cI10jBD/LW1WmFRAXsH8f25zXnpPAynUPZTLv8= MIME-Version: 1.0 From: SWISS-CORNER.RO Sender: SWISS-CORNER.RO Precedence: bulk Message-Id: <20130726121933.31530.653.48846.53449958.nl@kiccall.ro> Subject: Mari reduceri!!!! To: Mips Freebsd Date: Fri, 26 Jul 2013 12:19:33 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Reply-To: "SWISS-CORNER.RO" List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 12:24:26 -0000 Pentru a vedea _[online][1]_ acest mesaj personalizat [click aici][2] Va rugam sa adaugati adresa de mail **office@swiss-corner.ro** in Address Book pentru a va asigura ca primiti mesajele noastre in **Inbox**. [1]: # [2]: # [3]: http://nl.kiccall.eu/v/48846/53449958/00d4c2e7fb1f8bb18a28250976c6c96a= ?like=3Dfacebook [4]: http://nl.kiccall.eu/v/48846/53449958/00d4c2e7fb1f8bb18a28250976c6c96a= ?share=3Dtwitter [5]: http://nl.kiccall.eu/v/48846/53449958/00d4c2e7fb1f8bb18a28250976c6c96a= ?share=3Dlinkedin [6]: http://nl.kiccall.eu/v/48846/53449958/00d4c2e7fb1f8bb18a28250976c6c96a= ?like=3Dplusone [7]: http://nl.kiccall.eu/v/48846/53449958/00d4c2e7fb1f8bb18a28250976c6c96a= ?share=3Dpinterest Reduceri estivale in limita stocului disponibil! [8]: http://nl.kiccall.eu/clk/48846/53449958/996954/45f2aa7b9117e4648c21a3e= 25452b02f Blanc D`or Bracelet [9]: http://nl.kiccall.eu/clk/48846/53449958/996960/a4893d86a94283e0a0f41bf= 266bb5477 Orange ## [10]: http://nl.kiccall.eu/clk/48846/53449958/996956/045ecdc10dbdff51226585= 43ee681fdc red [11]: http://nl.kiccall.eu/clk/48846/53449958/996953/dc2656c1d56d68bd30892b= 8e283c36b3 Rosie Mumu Cow ## **[http://nl.kiccall.eu/clk/48846/53449958/996958/d4741e3ed73b9d5b487186652= eb6ec6a][12]** **[office@swiss-corner.ro][13]** [12]: http://nl.kiccall.eu/clk/48846/53449958/996952/cdc0f80e9704794cb802fe= 24535be332 [13]: mailto:office@swiss-corner.ro **0256/220 823** **0728/692 891** Pentru a vedea [online][14] acest mesaj personalizat [click aici][15] Pentru dezabonare instant [click aici][16]. [14]: http://nl.kiccall.eu/v/48846/53449958/00d4c2e7fb1f8bb18a28250976c6c96a [15]: http://nl.kiccall.eu/v/48846/53449958/00d4c2e7fb1f8bb18a28250976c6c96a [16]: http://nl.kiccall.eu/unsubscribe/653/48846/53449958/00d4c2e7fb1f8bb18= a28250976c6c96a