From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D12AC1381F3 for ; Thu, 24 Oct 2013 16:25:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0CE9BE09EB; Thu, 24 Oct 2013 16:25:16 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C6184E0983 for ; Thu, 24 Oct 2013 16:25:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id C8B1233DA38 for ; Thu, 24 Oct 2013 16:25:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5.5 tests=[AWL=-1.102, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.375, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luOlhcspUF4I for ; Thu, 24 Oct 2013 16:25:07 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 3756C33DA49 for ; Thu, 24 Oct 2013 16:25:05 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VZNiZ-0005C2-I6 for gentoo-user@gentoo.org; Thu, 24 Oct 2013 18:25:03 +0200 Received: from rrcs-71-40-157-251.se.biz.rr.com ([71.40.157.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Oct 2013 18:25:03 +0200 Received: from wireless by rrcs-71-40-157-251.se.biz.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Oct 2013 18:25:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: James Subject: [gentoo-user] Re: Kernel ricing Date: Thu, 24 Oct 2013 16:22:32 +0000 (UTC) Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 71.40.157.251 (Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14) X-Archives-Salt: bc60d8de-475a-4c22-a43a-e3d16a0c4877 X-Archives-Hash: 7e0efed923e9f58a877856697f78674b Adam Carter gmail.com> writes: > Some background: Wow!. Ok. Let me point out the obvious, that there are 2 basic ways to build a kernel: Natively on the local resources (CPU, ram etc) of the target system, and Cross Compiling. CrossCompiling is often much faster and even preferred, ymmv. Also it helps to know what your final (target) system will be? A security scanner, a firewall, a terminal server, web server? minimize portable workstation? This is important because, if you only want a firewall, there are several minimized standard C libraies that can be used in lieu of the standard LibC. ulibc, bionic, etc etc. A minimized sysetem involves much more, (usually) than a skinny, fast kernel. diffeent libraries need differnet kernel support (hooks). Staying with the x86 arch. first time down this path, is wise. If you want to build a minimized system, you need to first do a bit of reading. The best place to start is here: http://www.gentoo.org/proj/en/base/embedded/handbook/ The folks that inhabit embedded-gentoo, are leagues beyond my level of competency, just so you know. The gentoo embedded handbook will have lots of examples on building embedded (minimized) system. It's an interesting read too. > The CFLAGs used when building the kernel are set in the Makefile;# grep HOSTCFLAGS /usr/src/linux/MakefileHOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer I'd first avoid any changes to the /usr/src/linux/Makefile file, for now. Let's assume you are building kernels natively. First, minimize the system flags set in make.conf, and go thru the kernel options menu, or by hand, and removed as much stuff, particularly drivers, to a working bare minimum. Keep in mind what applications you will want to run eventuallly, as there is no point removing that relevant low-level codes, only to add them back in later. This process should lead to a radically reduced kernel size. I would leave the -O2 parameter set in the make.conf file. until you trim out all of the excess driver/firmware from the kernel, (/usr/src/linux/.config). Keep a copy of this kernel handy for booting/recovery. Because, as you go down the skinny path, you are going to get kernels that do not work, or do funky, undesirable things, imho. In fact in /boot, I keep many (experimental kernels), and copies of the system.map and the .config files too, matching them up by long names or date_stamps; particularly for refelection and deep analysis. > To build with other flags you set CFLAGS_KERNEL, so i've added a suitable -march to the standard ones for my system;export CFLAGS_KERNEL=" -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -march=amdfam10" I'd hold off on trimming this file, for now. Set kernel params in make.conf, which sould override setting like the -O2 option to -Os. The next thing I would do is build a second kernel kernel, changing only one parameter in the make.conf file. Change "O2" to "Os". Get both kernels stable. Then find some benchmarks relevant to what you want to do and run those on both kernels. I/O measurements is you intend to run lots of threads simultaneously. (Hint: you may want to read up on TLS, or Thread Local Storage as it pertains to kernel <-> libraries and the anticipated needs of memory, related to what your final target system applications will need to do. > then make, install, reboot. In my case the riced kernel is the same size > as the regular one, but the md5 is different. Its been up for an hour with no obvious issues, and does seem snappier, but of course my brain is full of cognitive bias. Has anyone else played with this? Any good or bad outcomes? Same size? You did not change -02 to -Os. Did you go thru menuconfig and trim out all of the extra drivers and things not needed (or manually in the /usr/src/linux/.config file) ? Comparing these -O2 to -Os speed/benchmark rewsults will first tell you which path to go down for all of your future minimiztion efforts. I also want to reiterate here: Vapier, Solar, Armin76 and many others on gentoo-embedded group, know far more than I do, being a grasshopper in these matters...... The focus there is ARM arch, but the knowledge transcends architecture types. However those guys are really, really busy, and before they will interact with you, they will expect that you have done tons of reading and experimenting on your own. You can look at the archive to gentoo embedded, for relevant postings. x86 use to have lots of efforts, today you have to research the atom or newere AMD arch sites to find some particular details and ideas. And as you switch architectures, thing get complex, but, that is where the real fun is. Most folks that spent years learning to minimize x86 have moved on to Mips, ARM or such as the work/benefit is far greater. I'm also a bit scattered (my friends refer to me as an interrupt processor with no return vector)..... just so you know.... So compare -O2 to -Os with all else being the same and post back. hth, James