[gentoo-user] Kernel ricing

[gentoo-user] Kernel ricing

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

The CFLAGs used when building the kernel are set in the Makefile;
# grep HOSTCFLAGS /usr/src/linux/Makefile
HOSTCFLAGS   = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2
-fomit-frame-pointer

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"

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?

[-- Attachment #2: Type: text/html, Size: 826 bytes --]

Re: [gentoo-user] Kernel ricing

[Alan McKinnon]

On 24/10/2013 10:58, Adam Carter wrote:
> The CFLAGs used when building the kernel are set in the Makefile;
> # grep HOSTCFLAGS /usr/src/linux/Makefile
> HOSTCFLAGS   = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2
> -fomit-frame-pointer
> 
> 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"
> 
> 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?
> 


James is the boy to answer up here. He'll give you a decent answer sans
cognitive bias.

I see all you've done is specify -march; what does the build system
build for without that setting?



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Kernel ricing

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

>
> I see all you've done is specify -march; what does the build system
> build for without that setting?
>
>
Does your question imply that more may happen to the CFLAGs than them just
being passed to gcc? I have no idea, so just assumed gcc does whatever it
does when no -march is supplied, which i guess is just generic x86-64 stuff.

I figured that just -march=amdfam10 was a good start, since it implies MMX,
SSE, SSE2, SSE3, SSE4A, 3DNow!, enhanced 3DNow! and ABM, but i may add the
rest of my make.conf CFLAGs since I dont have any issues with any other
software on this system. Is that fair reasoning?

[-- Attachment #2: Type: text/html, Size: 939 bytes --]

Re: [gentoo-user] Kernel ricing

[Alan McKinnon]

On 24/10/2013 12:58, Adam Carter wrote:
>     I see all you've done is specify -march; what does the build system
>     build for without that setting?
> 
> 
> Does your question imply that more may happen to the CFLAGs than them
> just being passed to gcc? I have no idea, so just assumed gcc does
> whatever it does when no -march is supplied, which i guess is just
> generic x86-64 stuff.
> 
> I figured that just -march=amdfam10 was a good start, since it implies
> MMX, SSE, SSE2, SSE3, SSE4A, 3DNow!, enhanced 3DNow! and ABM, but i may
> add the rest of my make.conf CFLAGs since I dont have any issues with
> any other software on this system. Is that fair reasoning?

I now officially need new spectacles. I read -march=amdfam10 and my
eyeballs told my brain it was "arm"

<sigh>

Please ignore this entire sub-thread :-)



-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Kernel ricing

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:


> I now officially need new spectacles. I read -march=amdfam10 and my
> eyeballs told my brain it was "arm"
> <sigh>

As an old fart, to a fledgling old-fart; its because ARM is taking over
the world, that your brain performed this superposition transformation. Your
glasses are most likely fine. You subconcience is smarter than your
waking (carnal?) consience. Trust the force, luke......




> Please ignore this entire sub-thread 

The fact of the matter is this. If I knew back then, what I know
now, I would not even fart around with x86* architectures on keen
issues of minimization. There is so much going on with ARM.
Minimization is about low power. The paradigm shift to low
power (the lowest heat) allows for for the greatest transistor
concentration ==> smallest size.  ARM has beaten them all, AMD
sees the light and is working on a myriad of hybrid SOCs, design
specifically for tight target implementations. Samsung is killing
the world, with ARM and open source linux. 


Still, to get a taste for minimization, there is nothing like
old (Gentoo) i586 and i486 sources and the 2.series of kernels
to see just how small you can get (sub 1 Mbyte.....?).
I've heard of kernels around 100Kb, in the old days.

These kernels FLY! but may not do all you eventually need....
TLS and such make it an infinite soup of trial and testing.

hth,

James

Re: [gentoo-user] Re: Kernel ricing

[Alan McKinnon]

On 24/10/2013 17:26, James wrote:
> Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
> 
> 
>> I now officially need new spectacles. I read -march=amdfam10 and my
>> eyeballs told my brain it was "arm"
>> <sigh>
> 
> As an old fart, to a fledgling old-fart; 

Now we can have a willy-waving contest!

I bet I'm an older fart than you are! nya-nya-nya-naaaaaa! <sung to the
tune of a teasing 6 year old)

its because ARM is taking over
> the world, that your brain performed this superposition transformation. Your
> glasses are most likely fine. You subconcience is smarter than your
> waking (carnal?) consience. Trust the force, luke......

Nah, the specs need replacing. There are some funky tri-focal jobs that
distort my depth vision, and I have to turn my head straight to look at
anything (no more looking out of the corner of my eyes). Makes
motorcycle riding a real pain

>> Please ignore this entire sub-thread 
> 
> The fact of the matter is this. If I knew back then, what I know
> now, I would not even fart around with x86* architectures on keen
> issues of minimization. There is so much going on with ARM.
> Minimization is about low power. The paradigm shift to low
> power (the lowest heat) allows for for the greatest transistor
> concentration ==> smallest size.  ARM has beaten them all, AMD
> sees the light and is working on a myriad of hybrid SOCs, design
> specifically for tight target implementations. Samsung is killing
> the world, with ARM and open source linux. 

I'm waiting for our approved hardware suppliers to come out with a range
of 1U pizza box ARM servers that management will buy into. But first
they need to lose the idea that virtualization is the go-fast solution
for anything.

Almost every single machine I run except the database servers will fly
along on ARM. I'm especially eager to see what ARM does with high
traffic DNS caches. Intuition tells me they will handle 20,000
queries/sec without breaking a sweat and the Gig ethernet will max out
long before the cpu does; all at 1/4 of the price

> 
> 
> Still, to get a taste for minimization, there is nothing like
> old (Gentoo) i586 and i486 sources and the 2.series of kernels
> to see just how small you can get (sub 1 Mbyte.....?).
> I've heard of kernels around 100Kb, in the old days.
> 
> These kernels FLY! but may not do all you eventually need....
> TLS and such make it an infinite soup of trial and testing.
> 
> hth,
> 
> James
> 
> 
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Kernel ricing

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:

> I bet I'm an older fart than you are! nya-nya-nya-naaaaaa! <sung to the
> tune of a teasing 6 year old)

With all due respect, I was an " old-fart" in my youth. I use
to love sitting around campfires with old hunter (gathers?)
and shoot the shi____ about life.

Beside my tantrums are so ledgendary, they often lead to 
a circle of folks joining in and chanting childish limricks
to a rythymic dance.   The Tequila goddess usually follows
up my antics with show stopper (hoot_nanny) you cannot 
believe.........



> Nah, the specs need replacing. There are some funky tri-focal jobs that
> distort my depth vision, and I have to turn my head straight to look at
> anything (no more looking out of the corner of my eyes). Makes
> motorcycle riding a real pain

preening code and riding a harley are differnt things? Boy, I did
not get that memo.


> I'm waiting for our approved hardware suppliers to come out with a range
> of 1U pizza box ARM servers that management will buy into. But first
> they need to lose the idea that virtualization is the go-fast solution
> for anything.

Virtualization is easy to shoot down for management types. Just start
them on a task force adressing all of the security issues opened up
related to virtualization.... [1] 


> Almost every single machine I run except the database servers will fly
> along on ARM. I'm especially eager to see what ARM does with high
> traffic DNS caches. Intuition tells me they will handle 20,000
> queries/sec without breaking a sweat and the Gig ethernet will max out
> long before the cpu does; all at 1/4 of the price.

Well, 10 G Ethernet is coming to systems near you, sooner than later.
100 GE  is availabe for routers now, if you have loads of CASH....
Once again, Juniper is killing the competition, imho.


Beside, virtualization is about to take on new meaning. [2] Imagine
a state machine for handling low-level register-memory tasks, whilst a
concurrent, real-time linux kernel handles traditional routing engine tasks,
both running on the same "bare metal" in a new twist of
virtualization.......  Very secure to boot, unless the NSA influences
the foundry's methologies for laying out the "bare metal"......


On the memory side of things, there are many viable options that the
different ARM [3] vendors can choose from for such challenges. 

Personally, the memory type that accompany the GPU, I think will change the
game for such needs, when the GPU become fully integrated with the cpu
cores (like what happend to FPU) in various SOC offerings. Granted, Arm is
late to the communications embedded systems efforts, but many of the top
hardware designers in routing and networking, are working on 
ARM implementations for comm gear, as we speak. 

ARM is simply whipping the dog_snot out of the other architectures.......

 later,
James

[1] http://dl.acm.org/citation.cfm?id=2431216


[2]
http://www.arm.com/products/processors/instruction-set-architectures/armv8-r-architecture.php

[3] http://www.arm.com/products/processors/armv8-architecture.php

Re: [gentoo-user] Re: Kernel ricing

[Bruce Hill]

On Thu, Oct 24, 2013 at 03:26:05PM +0000, James wrote:
> 
> specifically for tight target implementations. Samsung is killing
> the world, with ARM and open source linux. 
> 
> James

I'm not positive of it's architecture, but for 20 months I had a Samsung                                                                                                                 
Galaxy S running Android. This was by far the biggest POS I ever owned. From                                                                                                             
the first week it spontaneously rebooted, hung, and the performance was                                                                                                                  
horrible when it did run.                                                                                                                                                                
                                                                                                                                                                                         
I've since switched to an iPhone 4S, now running iOS 7.0.2. It Just Works (TM)
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

[gentoo-user] Re: Kernel ricing

[James]

Bruce Hill <daddy <at> happypenguincomputers.com> writes:

> > specifically for tight target implementations. Samsung is killing
> > the world, with ARM and open source linux. 

> > James
> 
> I'm not positive of it's architecture, but for 20 months I had a Samsung 
                                                                           
                 
> Galaxy S running Android. This was by far the biggest POS I ever owned.
From                                                                       
                                     
> the first week it spontaneously rebooted, hung, and the performance was  
                                                                           
                                   
> horrible when it did run.                                                
                           

2010 is ancient .  Most likely an early Android OS problem, not with the
processor......   Root the bitch and run embedded linux!                   
                                                              
> 
> I've since switched to an iPhone 4S, now running iOS 7.0.2. It Just Works (TM)


OK, have you seen this?

http://www.zdnet.com/2015-64-bit-arm-chips-in-iphone-5s-serve-up-taste-of-intel-free-future-for-apple-7000020524/


ymmv,
James

Re: [gentoo-user] Re: Kernel ricing

[Bruce Hill]

On Thu, Oct 24, 2013 at 05:31:08PM +0000, James wrote:
> > 
> > I'm not positive of it's architecture, but for 20 months I had a Samsung 
> > Galaxy S running Android. This was by far the biggest POS I ever owned.
> >From                                                                       
> > the first week it spontaneously rebooted, hung, and the performance was  
> > horrible when it did run.                                                
> 
> 2010 is ancient .  Most likely an early Android OS problem, not with the
> processor......   Root the bitch and run embedded linux!                   

Do you have a link for that? Is that cyanogenmod or whatever?

I figured the OS was too much for the hardware. Other users around here
running later versions of Galaxy don't all have that problem, though some do.

> > I've since switched to an iPhone 4S, now running iOS 7.0.2. It Just Works (TM)
> 
> 
> OK, have you seen this?
> 
> http://www.zdnet.com/2015-64-bit-arm-chips-in-iphone-5s-serve-up-taste-of-intel-free-future-for-apple-7000020524/

No, but I got the 4S in August because it was free, and when I upgrade I can
skip 5 and go to 5S or whatever the second generation. I'll read that, thanks.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

[gentoo-user] Re: Kernel ricing

[James]

Bruce Hill <daddy <at> happypenguincomputers.com> writes:


> Do you have a link for that? Is that cyanogenmod or whatever?

This link popped up in 3 seconds using google:

http://reviews.cnet.co.uk/mobile-phones/how-to-root-your-samsung-galaxy-s3-50008588/


Old hardware is the best to experiment around with....imho.


Backup what you can! Personally, I'd do this on a non-critical
cell phone first to make sure it work. NOwadays, phone vendors
will try to auto-update your phone software/firmware, so do some 
research on your exact phone model, your carrier and the different
projects out there that best suit your goals....


Many other devices use the same uP so most codes written for similar
(family of) Processors will have codes you can compile and use.
Cross-Compiling is your friend!

SEandroid is way cool, from the folks I have spoken to.

good hunting!
James

Re: [gentoo-user] Re: Kernel ricing

[Tanstaafl]

On 2013-10-24 1:03 PM, Bruce Hill <daddy@happypenguincomputers.com> wrote:
> I'm not positive of it's architecture, but for 20 months I had a Samsung
> Galaxy S running Android. This was by far the biggest POS I ever owned. From
> the first week it spontaneously rebooted, hung, and the performance was
> horrible when it did run.
>
> I've since switched to an iPhone 4S, now running iOS 7.0.2. It Just Works (TM)

Oh, please, spare me the ridiculous apple fanboi crap-crud.

Just because you got a phone that was bad, and didn't bother to get it 
replaced, doesn't make all Galaxy S4 phones as bad as yours.

I'll tell you this, my Nexus 4 is absolutely rock-solid, and screaming 
fast, but that doesn't mean iPhones suck.

Re: [gentoo-user] Re: Kernel ricing

[Bruce Hill]

On Thu, Oct 24, 2013 at 01:36:37PM -0400, Tanstaafl wrote:
> 
> Just because you got a phone that was bad, and didn't bother to get it 
> replaced, doesn't make all Galaxy S4 phones as bad as yours.

Hey, dipstick! Apparently you can't distinguish between S and S4.  :-)
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Kernel ricing

[Tanstaafl]

On 2013-10-24 1:51 PM, Bruce Hill <daddy@happypenguincomputers.com> wrote:
> On Thu, Oct 24, 2013 at 01:36:37PM -0400, Tanstaafl wrote:
>>
>> Just because you got a phone that was bad, and didn't bother to get it
>> replaced, doesn't make all Galaxy S4 phones as bad as yours.
>
> Hey, dipstick! Apparently you can't distinguish between S and S4.  :-)

Lol! You're right, but the basis of the argument stands...

[gentoo-user] Re: Kernel ricing

[James]

Tanstaafl <tanstaafl <at> libertytrek.org> writes:

> 
> On 2013-10-24 1:03 PM, Bruce Hill <daddy <at> happypenguincomputers.com>
wrote:
> > I'm not positive of it's architecture, but for 20 months I had a Samsung
> > Galaxy S running Android. This was by far the biggest POS I ever owned. From
> > the first week it spontaneously rebooted, hung, and the performance was
> > horrible when it did run.
> >
> > I've since switched to an iPhone 4S, now running iOS 7.0.2. It Just
Works (TM)
> 
> Oh, please, spare me the ridiculous apple fanboi crap-crud.
> 
> Just because you got a phone that was bad, and didn't bother to get it 
> replaced, doesn't make all Galaxy S4 phones as bad as yours.
> 
> I'll tell you this, my Nexus 4 is absolutely rock-solid, and screaming 
> fast, but that doesn't mean iPhones suck.


Or does it? Look at what one of my favorite Aussie's [1]
has done for Android [2]. Got that on your iphome?

Plain truth. Apple sucks, and ripped off the MACH kernel
and passed on that work as their own, some decades ago.
Please don't hold apple up to me, as anything but a ripoff
of open source, much like the idiots in Redmond......

Still, my kids all use iphones, so who cares what any
one (idiot) consumer does.  They piss away money in the
apps stores all the time.....

I have hundreds of friends that design new chips, and some that build  Rf
devices for things that travel beyond Mach 7.....  I know what I'm talking
about with ARM. So stick to (technical) facts, not consumerisms.....


hth,
James


[1] http://www.coker.com.au/projects.html

[1] http://selinuxproject.org/page/SEAndroid

Re: [gentoo-user] Re: Kernel ricing

[Alan McKinnon]

On 24/10/2013 19:36, Tanstaafl wrote:
> On 2013-10-24 1:03 PM, Bruce Hill <daddy@happypenguincomputers.com> wrote:
>> I'm not positive of it's architecture, but for 20 months I had a Samsung
>> Galaxy S running Android. This was by far the biggest POS I ever
>> owned. From
>> the first week it spontaneously rebooted, hung, and the performance was
>> horrible when it did run.
>>
>> I've since switched to an iPhone 4S, now running iOS 7.0.2. It Just
>> Works (TM)
> 
> Oh, please, spare me the ridiculous apple fanboi crap-crud.
> 
> Just because you got a phone that was bad, and didn't bother to get it
> replaced, doesn't make all Galaxy S4 phones as bad as yours.
> 
> I'll tell you this, my Nexus 4 is absolutely rock-solid, and screaming
> fast, but that doesn't mean iPhones suck.
> 


Phones are like cars in that almost no-one makes a bad one anymore.

Pick a smart phone, any smart phone, and I can almost assure you that in
this vast cavern of a room where I work I will find 3 people within an
hour who have or had that phone. The last smart phone model that had a
serious defect that applied across the range was the iPhone that had
antenna problems.

Since then everyone's shit just works for the most part like it was
designed to. Even the Windows 8 thingy from Nokia. It does what it says
on the box.

Yes, software bugs exist such as Apple's maps but that's not phone
design, that's bad data fed into a db that an app uses

These days the most relible way to pick a phone that will work for you
is the one that a) runs the software you like if you care about such
things and b) feels nice in your hand and fits in your pocket

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Kernel ricing

[Grant]

> The fact of the matter is this. If I knew back then, what I know
> now, I would not even fart around with x86* architectures on keen
> issues of minimization. There is so much going on with ARM.
> Minimization is about low power. The paradigm shift to low
> power (the lowest heat) allows for for the greatest transistor
> concentration ==> smallest size.  ARM has beaten them all, AMD
> sees the light and is working on a myriad of hybrid SOCs, design
> specifically for tight target implementations. Samsung is killing
> the world, with ARM and open source linux.

NASDAQ:ARMH

- Grant

Re: [gentoo-user] Kernel ricing

[Walter Dnes]

On Thu, Oct 24, 2013 at 09:58:17PM +1100, Adam Carter wrote

> I figured that just -march=amdfam10 was a good start, since it implies
> MMX, SSE, SSE2, SSE3, SSE4A, 3DNow!, enhanced 3DNow! and ABM, but i
> may add the rest of my make.conf CFLAGs since I dont have any issues
> with any other software on this system. Is that fair reasoning?

  Two points...

1) Are you cross-compiling, or building on the system that'll be running
the kernel?  If the build machine will be running the kernel, use
"-march=native".  It detects what cpu you're running on and builds
accordingly.

2) Use the flags "-fno-unwind-tables -fno-asynchronous-unwind-tables" to
eliminate .eh_frame bloat.  See the mailing list archive at
http://comments.gmane.org/gmane.linux.busybox/36695 for the gory
details.  The guys at busybox are anal about code bloat; this is an
important issue for them.

3) Unless you're debugging, you can get additional size reduction with
the "-fomit-frame-pointer" flag.

  My make.conf has the following CFLAGS line...

CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Kernel ricing

[the]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/24/13 12:58, Adam Carter wrote:
> The CFLAGs used when building the kernel are set in the Makefile; #
> grep HOSTCFLAGS /usr/src/linux/Makefile HOSTCFLAGS   = -Wall
> -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
> 
> 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"
> 
> 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?
> 
I was thinking of compiling The Kernel with custom cflags, but never
tried. Looking forward to your report.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSaQkgAAoJEK64IL1uI2ha6/UH/RHCDZSaarmnx9by7YSk39RQ
mtsqQTP/SMaXWj05qiwfL6FRnX+OZqUwC8tWIS2hqNN0y+s8p8LN2nnRR3NPbfA/
ZEeZuZKahNv1XXo9VyuvjEsVEwNp7YOYKJgPt02ucbvp/+NELPJvBSeBsjAQ/2g7
fe60i5M7ms074ADqSjuS5gaH2JGSzINwBZB82OcjEXH7uV8muU/+vDkEIYonJt60
OkoP+qEqWgpPqF2K6MiUXakY3sgP9IDEj4JiQAYSNppa+xxB3eiYyCxQJB3DVSGh
US3ofLiq+9LG9+f36VLy1IQOM0gJYWEV5AxmRKaoWwWByKTosJGvqUXlIIG2gas=
=aYgY
-----END PGP SIGNATURE-----

[gentoo-user] Re: Kernel ricing

[James]

Adam Carter <adamcarter3 <at> 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