Re: [gentoo-user] Re: A pared down kernel config

2008-01-07 Thread Florian Philipp

On Sun, 2008-01-06 at 17:15 -0600, [EMAIL PROTECTED] wrote:
 Florian Philipp [EMAIL PROTECTED] writes:
 
  There's a reason for the existence of genkernel - it's so that you don't 
  have to go through all this pain and suffering, and can instead remove 
  stuff a bit at a time with reasonable confidence it won;t blow up in 
  your face :-)
  
 
  There is a fairly easy trick to get rid of pointless options like unused
  drivers even if you are not sure about your hardware or the kernel
  options themselves: 
  Compile them as modules, then boot the new kernel. If the modules don't
  get loaded (lsmod is your friend) and everything works fine, throw them
  out of your configuration.
 
 Nice... a small question: how do you keep up with what gets installed?
 Do you ferret them out at /lib/modules with cmds like 
 find . -name '*.ko'
 
 Or is there a log created at compile time.. or maybe create one like
 make modules_intall mymod.log.  Just thinking outload.
 
 Following a `genkernal all' I saw a very big list get installed but didn't
 think to log them.
 
 I guess it would be harmless to just run the `make modules_intall' part
 again and catch a list.
 

I think you search for modprobe -l :)

Have a nice day!


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-user] Re: A pared down kernel config

2008-01-06 Thread Alan McKinnon
On Sunday 06 January 2008, [EMAIL PROTECTED] wrote:
 People in this thread speak of 2 and 3 boots and editing in between
 in the same message where `5 minutes' is mentioned.  That doesn't
 wash. You're way past that time frame.  But still not in the guiness
 book realm I guess... hehe.

I guess the English phrase '5 minutes' is a symlink to another longer 
phrase: 'A reasonably short period of time that doesn't cause me 
massive amounts of inconvenience'. I have a spare 2.6.23-gentoo source 
tree here with everything enabled. With no changes to the config a 
second 'make' still takes 2m29.414s

2 to 3 boots with a new kernel version, especially one where sub-systems 
like libata got moved around, sounds perfectly reasonable.

  Removing all these unused drivers is the single largest improvement
  in reducing kernel size. The general rule with drivers is that if
  you are familiar with YOUR hardware and you've never heard of
  something in the config then you don't have it and don't need it
  :-)

 Just to know more on this... Is there really any reason to worry
 about kernel size... I mean in most cases with a standard desktop
 install?

By kernel size I actually meant disk space used, including it's 
modules.

Seeing as almost every other mainstream distro gives you a full-featured 
kernel with all modules included and /lib/modules/`uname -r`/ weighs in 
at around 400M, I'd say no, it's not worth worrying about.

Some people do worry about it, and that's cool for them. Some folk do 
lots of kernel testing, if they have 10 kernel versions on disk then it 
does become a factor. The beauty of gentoo is that if you don't feel 
like caring, you don't have to.

alan

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com
--
gentoo-user@lists.gentoo.org mailing list



Re: [gentoo-user] Re: A pared down kernel config

2008-01-06 Thread Alan McKinnon
On Sunday 06 January 2008, [EMAIL PROTECTED] wrote:
 Erik [EMAIL PROTECTED] writes:
  [EMAIL PROTECTED] skrev:
  Then you are stuck figuring out what on earth a hypervisor is.
 
  Alt+F2
  wp:hypervisor
  ENTER

 Hey thats a pretty neat trick.  Now if I wondered if that would be
 important since I plan to run a vmware application... I will take
 more digging.  It mentions vmware but not clear if this is important
 to it.

No, it's not relevant in this case. vmware is a virtualisation app, but 
doesn't use a hypervisor - it's a regular application with some custom 
kernel modules. kvm, xen and (I think) qemu do use hypervisors so this 
feature needs to be in the kernel for them.

Virtualisation is a vast field covering many many different techniques, 
each with their own pros and cons. The technique vmware uses makes it 
very easy to install, use and configure your virtual machine (it's just 
a bunch of big files), but the performance frankly sucks. At the other 
extreme you get VServer which runs like a bomb but is tightly tied onto 
the host machine running it. Somewhere in the middle we have xen and 
it's simpler cousin kvm - due to hypervisors they give very good 
performance and are relatively easy to configure and maintain.

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com
-- 
gentoo-user@lists.gentoo.org mailing list



Re: [gentoo-user] Re: A pared down kernel config

2008-01-06 Thread Jan-Hendrik Zab
On Sun, 6 Jan 2008 10:58:12 +0400
Yahya Mohammad [EMAIL PROTECTED] wrote:

   Just to know more on this... Is there really any reason to worry
   about kernel size... I mean in most cases with a standard desktop
   install?
  
  
  yes. Bigger kernel = more cpu cache used up = slower system.
 
 Does all of the kernel reside in cpu cache all the time? Or can parts
 of it get moved to system RAM? What about modules that are loaded from
 disk?

No, it does not. The CPU caches are used differently. Partly, they
become something like read-ahead caches due to the fact that the CPU
can only read hole cache lines.

See http://lwn.net/Articles/252125/ for a good and recent documentation.

Jan-Hendrik Zab

-- 
Jan-Hendrik Zab [EMAIL PROTECTED]
Tel: +49 (0)15154625819
-- 
gentoo-user@lists.gentoo.org mailing list



Re: [gentoo-user] Re: A pared down kernel config

2008-01-05 Thread Hemmann, Volker Armin
On Samstag, 5. Januar 2008, [EMAIL PROTECTED] wrote:
 Hemmann, Volker Armin [EMAIL PROTECTED] writes:
  On Samstag, 5. Januar 2008, [EMAIL PROTECTED] wrote:
 
  you want to read this:
  http://www.kroah.com/lkn/

 Thanks... I'm getting started now.

  configuring a kernel is a matter of minutes. And seconds, if you just
  copy over the old config and do 'make oldconfig'.

 Yeah if you  do that... but if you want to go through and look at all the
 different stuff and try to understand the minutes, and seconds
 theory is history.

even than it does not take that ling.


  It is not hard - the first time read all the help texts and think about
  them. That is the hardest part. Do you really need I2O? Almost nobody
  does. I2C? Yes. ...

 You are clearly on a much different plain than I.
 `Read all the help texts and think about them.'  If you can do that and
 feel you've understood even a small portion of it, that puts you way
 up the knowledge ladder compared to us lesser endowed.

you have to start somewhere. When compiled my first kernel (2.2.14) nobody 
hold my hand - and I needed several tries to get a booting one. But over the 
years a lot of experience accumulates. Do I need fibrechannel? Certainly not.


 Unless you mean all those places that say `if unsure just say yes'.

is there better help? If you don't know what to do, say yes. Easy!

 Or better yet those that say:
 `There is no help available for this kernel option.'

there are only very few of those - and usually it is best to let them 
unchanged.

 Here is a good one.

  CONFIG_PARAVIRT:
   | Paravirtualization is a way of running multiple instances of
   | Linux on the same machine, under a hypervisor.  This option
   | changes the kernel so it can modify itself when it is run
   | under a hypervisor, improving performance significantly.
   | However, when run without a hypervisor the kernel is
   | theoretically slower.  If in doubt, say N.

 Unless you are talking about the last `If in doubt...'
 Then you are stuck figuring out what on earth a hypervisor is.

Nope, the helptext tells you exactly what it does. And it tells you, that you 
can say no, if you don't know what to do here.


 Or here:
   | CONFIG_HPET_TIMER:
   |
   | This enables the use of the HPET for the kernel's internal timer.
   | HPET is the next generation timer replacing legacy 8254s.
   | You can safely choose Y here.  However, HPET will only be
   | activated if the platform and the BIOS support this feature.
   | Otherwise the 8254 will be used for timing services.

 Unless you mean `You can safely choose Y here' then you have a few
 days work figuring out what any of that means.

no, you have some SECONDS to figure it out:
gg:hpet
(with konqueror).
And what is wrong with 'you can safely choose Y here'? It tells you that it 
does not harm to turn it on. So why turn it off? Why think about it, if you 
don't know what a hpet is (btw, hpet is also explained in detail in the 
Documentation directory. a single grep -R hpet /usr/src/linux/Documentation 
would show you where).


 This goes on and on through the menus..
 So no.. I don't think we are dealing with minutes here.

you can, if you accept that you should use the recommended choice, expet when 
ou knmow what you are doing.


 If you mean you can get it done if you just skip all of that then
 yes it might be minutes.

 If you wanted to pare down all the junk that is in a default
 config... now you are taking days even weeks to get a handle on that.

to de-junk a default config - even if you don't know what you do, is in realm 
of half an hour to an hour. If you read everything.

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: A pared down kernel config

2008-01-05 Thread Alan McKinnon
On Saturday 05 January 2008, [EMAIL PROTECTED] wrote:
  to de-junk a default config - even if you don't know what you do,
  is in realm of half an hour to an hour. If you read everything.

 Do you have a de-junked .config that I can diff against the
 default.. it would be a way to see what kinds of things get dropped.

Drivers for stuff you don't need and you will likely never use. Like ham 
radio stuff, v4linux (first version), I20, on a notebook all the 
enterprise-grade connect-a-machine-to-storage-stuff like iSCSI and 
Infiniband, all of ISA and MCA and the pre-pci bus drivers, old disk 
types like mfm and on modern boards usually even IDE as well. 

Removing all these unused drivers is the single largest improvement in 
reducing kernel size. The general rule with drivers is that if you are 
familiar with YOUR hardware and you've never heard of something in the 
config then you don't have it and don't need it :-)

Complete kernel sub-systems are a bit harder, although some are still 
obvious. Like virtualisation. I assure you that if you have never heard 
of kvm and paravirt, then you certainly don't need it.

With other stuff I usually end up leaving them in and removing things 
gradually as I compile the next kernel and learn more about stuff out 
there. If say HPET intrigues you and you want to know more, then Google 
it. Tomorrow you can do another one.

Like I said in an earlier mail, it's not an easy process. It's only easy 
if you know most of it already - like Volker. I'd guess he has long 
since forgotten what it took to learn everything he knows, so of 
course It's obvious!...

Comparing his and your configs is mostly pointless as your machines will 
differ considerably. The config file is 70k and even on two recent 
standard ubuntu configs the differences are over 1000 lines. Good luck 
with comparing that lot and trying to figure out what's going on :-)

alan

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: A pared down kernel config

2008-01-05 Thread Erik
[EMAIL PROTECTED] skrev:
 Then you are stuck figuring out what on earth a hypervisor is.
   
Alt+F2
wp:hypervisor
ENTER

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: A pared down kernel config

2008-01-05 Thread Hemmann, Volker Armin
On Sonntag, 6. Januar 2008, [EMAIL PROTECTED] wrote:
 Alan McKinnon [EMAIL PROTECTED] writes:
  On Saturday 05 January 2008, [EMAIL PROTECTED] wrote:
   to de-junk a default config - even if you don't know what you do,
   is in realm of half an hour to an hour. If you read everything.
 
  Do you have a de-junked .config that I can diff against the
  default.. it would be a way to see what kinds of things get dropped.
 
  Drivers for stuff you don't need and you will likely never use. Like ham
  radio stuff, v4linux (first version), I20, on a notebook all the
  enterprise-grade connect-a-machine-to-storage-stuff like iSCSI and
  Infiniband, all of ISA and MCA and the pre-pci bus drivers, old disk
  types like mfm and on modern boards usually even IDE as well.

 Thanks... but you hit on something there that can throw you.
   scsi stuff.

you need scsi for:
sata harddisk
sata cdroms
usb sticks
usb harddrives
usb cdroms (like in an external case)
usb card readers.

In fact, if you enable sata, scsi harddisk support is enabled automatically.


 I've never used a scsi hard drive in my life but not that long ago
 linux users needed scsi support for many of the cdrom drives.  

no.
You never needed scsi for 'standard' atapi cdrom drives. Once upon a time you 
needed scsi-ide emulation for burning and even that is gone.

 I doubt 
 that is still the case but it might be.  But my point is that even
 when you think you know something isn't needed it might be in some
 context you haven't thought of.

well, the scsi-usb relation is explained in the help texts.


 People in this thread speak of 2 and 3 boots and editing in between in
 the same message where `5 minutes' is mentioned.  That doesn't wash.
 You're way past that time frame.  But still not in the guiness book
 realm I guess... hehe.

since the kernel make system is smart, only the stuff that changed is redone. 
So 3 reboots+2recompiles are easily done in 5minutes.


 Just to know more on this... Is there really any reason to worry about
 kernel size... I mean in most cases with a standard desktop install?


yes. Bigger kernel = more cpu cache used up = slower system.

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: A pared down kernel config

2008-01-05 Thread Yahya Mohammad
  Just to know more on this... Is there really any reason to worry about
  kernel size... I mean in most cases with a standard desktop install?
 
 
 yes. Bigger kernel = more cpu cache used up = slower system.

Does all of the kernel reside in cpu cache all the time? Or can parts
of it get moved to system RAM? What about modules that are loaded from
disk?
-- 
gentoo-user@lists.gentoo.org mailing list