Watch out for 10.3 kernel (slow)
pedlo
Why do they ship a kernel compiled with lots of debug symbols and not
optimized?
Default gcc flag in config file is -Os! (better be -O2)
After careful recompilation the distro really rocks, but default kernel is a
shame.
pedlo
Neil Ellwood
Must be your system. Works well for me.
--
Neil
reverse ra and delete l
pedlo
Instructions are in /usr/src/linux/readme.suse
"Neil Ellwood" <cral.el...@btopenworld.com> ha scritto nel messaggio
news:OZ-dnb0brMAjNbHa...@bt.com...
houghi
If it ain't broke, don't fix it. That goes for both the kernel and the
way people post in this group.
houghi
--
This space left blank intentionaly
pedlo
> way people post in this group.
>
> houghi
> --
You're absolutely right.
But please, let's do something to stop people say "Suse is slow and heavy".
I totally disagree in running a Ferrari with half cylinders disabled, I hope
you understand.
pedlo
houghi
Well, then stop saying it. First of all, I have NEVER been able to
compile my own kernel, so that would mean that if I tried, I would not
be able to run anything.
Secondly, there is a reason that it is compiled the way it is.
Thirdly, if you believe you can do better, please go to the factory
mailinglist and solve the problem for 11.0
Also you make it sound as if openSUSE developers do not care and that is
not true, as you would know if you would frequent the factory
mailinglist.
If it is broke, fix it and fixing is not done here. It needs to be done
before it gets out.
pedlo
>First of all, I have NEVER been able to
> compile my own kernel, so that would mean that if I tried, I would not
> be able to run anything.
No need to comment this.
Compiling in Suse is more or less 5 easy steps.
> Secondly, there is a reason that it is compiled the way it is.
I'd like to know it.
> Thirdly, if you believe you can do better, please go to the factory
> mailinglist and solve the problem for 11.0
Maybe one day.
> Also you make it sound as if openSUSE developers do not care and that is
> not true, as you would know if you would frequent the factory
> mailinglist.
I'm NOT saying developers don't care! geeez...
But if you have a reason for that kind of compilation, I honestly would like
to know it. My observation came from a direct comparison between Mandriva's
kernel and OpenSuse 10.3, and they are extremely different in terms of
speed.
That's it.
> If it is broke, fix it and fixing is not done here. It needs to be done
> before it gets out.
Well, i ADJUSTED it, and I thought people should share improvements.
> houghi
pedlo
houghi
>> Well, then stop saying it.
> No way, I have the right to speak and I'm not spamming.
Sure you do, yet somebody said we must be stop saying it.
>>First of all, I have NEVER been able to
>> compile my own kernel, so that would mean that if I tried, I would not
>> be able to run anything.
> No need to comment this.
> Compiling in Suse is more or less 5 easy steps.
That might well be for you. I was never able to do it.
>> Secondly, there is a reason that it is compiled the way it is.
> I'd like to know it.
That has been and can be discussed best on the factory mailinglist where
the developers are.
>> Thirdly, if you believe you can do better, please go to the factory
>> mailinglist and solve the problem for 11.0
> Maybe one day.
Why not now? It is also the place where you can find out the reason why
it is compiled that way.
>> Also you make it sound as if openSUSE developers do not care and that is
>> not true, as you would know if you would frequent the factory
>> mailinglist.
> I'm NOT saying developers don't care! geeez...
I am NOT saying that you did. I said it sounded as if you did.
> But if you have a reason for that kind of compilation, I honestly would like
> to know it. My observation came from a direct comparison between Mandriva's
> kernel and OpenSuse 10.3, and they are extremely different in terms of
> speed.
> That's it.
That answer can be found and given on the factory mailinglist.
>> If it is broke, fix it and fixing is not done here. It needs to be done
>> before it gets out.
> Well, i ADJUSTED it, and I thought people should share improvements.
I agree. However I have not seen your improvement. Also the best place
for such an improvement is on the factory mailinglist where it will
benefit the much more people.
houghi
--
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it on
the computer.
Nikos Chantziaras
>>> First of all, I have NEVER been able to
>>> compile my own kernel, so that would mean that if I tried, I would not
>>> be able to run anything.
>> No need to comment this.
>> Compiling in Suse is more or less 5 easy steps.
>
> That might well be for you. I was never able to do it.
Then you're missing one of the good things in Linux. It's so easy to it
in openSUSE. You only need the kernel source, ncurses-devel package and
gcc installed:
cd /usr/src/linux
make cloneconfig
make menuconfig
Disable "General Setup-->Optimize for size"
Choose your CPU in "Processor type and features-->Processor family"
Select 1000Hz in "Processor type and features-->Timer frequency"
Disable squashfs in "Filesystems-->Miscellaneous filesystems-->squashfs"
(Because that one won't compile due to a bug, but you don't need that
filesystem anyway.)
After then, exit, confirm with "yes" in order to save the configuration,
and then do:
make (this will take quite some time; go eat dinner)
make modules_install
make install
Reboot. Finished. Enjoy a more responsive system due do openSUSE using
laggy and non-responsive settings as defaults.
One thing I disagree with you is that even though you don't know how to
build a kernel you still claim that there's not much difference between
the RECOMMENDED optimization settings of the vanilla kernel and the
choices of openSUSE. Simply go ahead and do what I described above and
judge for yourself.
Paul J Gans
>> houghi
>pedlo
The default kernel has all sorts of stuff in it to fit
the hardware that it might run into. By compiling your
own you can make the OS both smaller and faster.
For most of us, it doesn't matter enough to take the time
to do it.
--
--- Paul J. Gans
houghi
> The default kernel has all sorts of stuff in it to fit
> the hardware that it might run into. By compiling your
> own you can make the OS both smaller and faster.
>
> For most of us, it doesn't matter enough to take the time
> to do it.
My thoughts exactly. The fact that you can does not mean that you must.
houghi
--
Listen do you hear them drawing near in their search for the sinners?
Feeding on the power of our fear and the evil within us.
Incarnation of Satan's creation of all that we dread.
When the demons arrive those alive would be better off dead!
houghi
> Reboot. Finished. Enjoy a more responsive system due do openSUSE using
> laggy and non-responsive settings as defaults.
I never experienced amy leggy and non-responsiveness. I will try this
evening when I am home.
In your explanation, I missed the part of backing up the current
situation, so that I can go back to what I have. I will figure that out
first before I go ahead.
> One thing I disagree with you is that even though you don't know how to
> build a kernel you still claim that there's not much difference between
> the RECOMMENDED optimization settings of the vanilla kernel and the
> choices of openSUSE. Simply go ahead and do what I described above and
> judge for yourself.
Uhm, I did not claim such a thing. I claim there is a reason that they
do it the way they do it. I also claim that I never experienced any
problems. Yes, I have seen machines boot faster then what I have now. To
me that is a non-issue. The working of the system is almost the same
with e.g. openSUSE or DSL.
To me the speedlimitations I notice are PEBCAK.
Vahis
<snip>
It's so easy to it
> in openSUSE.
I wanted to try.
You only need the kernel source, ncurses-devel package and
> gcc installed:
I have those.
>
> cd /usr/src/linux
> make cloneconfig
This is fine, no errors.
> make menuconfig
# make manuconfig
make[1]: *** No rule to make target `manuconfig'. Stop.
make: *** [manuconfig] Error 2
Something missing there?
Vahis
--
"Only wimps use tape backup: _real_ men just upload their important
stuff on ftp, and let the rest of the world mirror it ;)"
Linus Torvalds 1996.
Paul Stynen
> This is fine, no errors.
>
>> make menuconfig
>
> # make manuconfig
> make[1]: *** No rule to make target `manuconfig'. Stop.
> make: *** [manuconfig] Error 2
>
> Something missing there?
Yes some glasses :)
must be 'menuconfig' instead of 'manuconfig'
Paul.
Vahis
Actually my wife did show me an ad this morning where two pairs of
glasses were offered for the price of one. I wonder why...
Thanks
Nikos Chantziaras
> Nikos Chantziaras wrote:
>> Reboot. Finished. Enjoy a more responsive system due do openSUSE using
>> laggy and non-responsive settings as defaults.
>
> I never experienced amy leggy and non-responsiveness. I will try this
> evening when I am home.
>
> In your explanation, I missed the part of backing up the current
> situation, so that I can go back to what I have. I will figure that out
> first before I go ahead.
Sorry for that. Before you start, you can backup your current kernel
modules with (you don't have to be root for that):
cd /lib
tar -cf /home/houghi/modules-backup.tar ./modules
Or you can use your favorite GUI to backup /lib/modules.
*After* the build and installation of the kernel, you will find some
files with the "*.old" extension under /boot (the openSUSE "make
install" installation backs-up the old kernel automatically). Simply:
cp /boot/*.old /home/houghi
(Or simply with your GUI file manager.)
before you reboot. If you wish to revert after the new kernel, you
restore everything back (you need to be root). The modules with:
cd /lib
tar -xf /home/houghi/modules-backup.tar
and the kernel itself by removing the *.old extension from the backed-up
files in /boot and moving them to /boot overwriting what's there.
If you can't boot from hard disk in order to restore the kernel, simply
boot the system from CD/DVD. I've done so countless times.
>> One thing I disagree with you is that even though you don't know how to
>> build a kernel you still claim that there's not much difference between
>> the RECOMMENDED optimization settings of the vanilla kernel and the
>> choices of openSUSE. Simply go ahead and do what I described above and
>> judge for yourself.
>
> Uhm, I did not claim such a thing. I claim there is a reason that they
> do it the way they do it.
Yes, there are reasons. The user shouldn't be concerned too much about
the reasons openSUSE has to offer a slow kernel though. One of the
reasons for the slow kernel is of course that the user can build a fast
kernel if he wants to. Hey, this is Linux, don't forget that ;)
There is a drawback to a self-built kernel though. When a new kernel
update is issued by openSUSE, you will have to do a full download of the
new kernel rather than simply getting the delta-RPMs which of course
needs more time (depending on your internet connection's speed).
> I also claim that I never experienced any
> problems. Yes, I have seen machines boot faster then what I have now. To
> me that is a non-issue. The working of the system is almost the same
> with e.g. openSUSE or DSL.
>
> To me the speedlimitations I notice are PEBCAK.
Maybe it depends on how you use your system. Games and multimedia?
Just web and office? But don't forget; we're talking about GCC's -Os vs
-O2 here! The speed difference *is* there, and there's a reason why the
vanilla kernel uses -O2 (if you read the description in the kernel
config dialog, it says right there that -Os is slow and only useful for
distribution kernels where size if more important than speed).
And besides, using Linux without ever having build the kernel by
yourself is lame :D
Nikos Chantziaras
> On Mon, 05 Nov 2007 23:16:39 +0200, Nikos Chantziaras <rea...@arcor.de> wrote:
>
>> Then you're missing one of the good things in Linux. It's so easy to it
>> in openSUSE. You only need the kernel source, ncurses-devel package and
>> gcc installed:
>>
>> cd /usr/src/linux
>> make cloneconfig
>> make menuconfig
>
> And how could I create a custom rpm package of this shiny new kernel?
> Since I have to maintain 5 machines it would be a pain to compile it 5 times.
> Can you help me there compatriot?
There is a "make rpm" target, but I think it won't help produce an
openSUSE RPM, since "rpm" is a target of the vanilla kernel and I don't
see any openSUSE modifications in it. I could be wrong though.
One thing you can try is doing a "make" and then
cd /usr/src
tar -cf /mnt/somenetworkshare/linux.tar ./linux
Then, after installing the kernel source RPM on the target machine:
cd /usr/src
tar -xf /mnt/somenetworkshare/linux.tar
cd linux
make install_modules
make install
(on the target machine)
The plan is that the kernel has to be built on one machine, and then
installed on multiple ones by copying the whole build tree. tar ensures
that file access times won't change, otherwise "make" would recompile
everything and that's what we're trying to avoid.
Btw, this assumes that all machines use the same type of CPU (all of
them P4, all of them Core 2, etc.) If not, you will have to configure
the kernel for a "generic" CPU, or take the time and compile the kernel
on each machine individually.
Vahis
> Paul J Gans wrote:
>> The default kernel has all sorts of stuff in it to fit
>> the hardware that it might run into. By compiling your
>> own you can make the OS both smaller and faster.
>>
>> For most of us, it doesn't matter enough to take the time
>> to do it.
>
> My thoughts exactly. The fact that you can does not mean that you must.
>
> houghi
I did this and now I'm running the new compiled kernel.
It took two hours to compile.
There were a few warnings, so I was scared it won't boot.
It booted fine but I haven't seen any difference in anything.
I wonder what will happen the next time there is a kernel patch available.
Vahis
houghi
> I wonder what will happen the next time there is a kernel patch available.
Nothing. As with all software. Either you let openSUSE handle it, or you
handle it. The kernel yu run now isn't the concern of openSUSE anymore.
Be glad that it is that way. Imagine that you have edited the kernel in
such a way that a certain part had changed sourcecode. The reason might
be that it doesn't run your specific hardware otherwise.
Now imagine that just that part is updated. You get the update and now
your software does not work anymore.
The same goes for any software. Once you compiled it yourself, YOU are
responsible for updates and not YOU. ;-)
houghi
--
>>>> Run the following from the bashprompt if you have the kernel sources
for I in `find /usr/src/linux/ -name *.c`; \
do A=`grep -i -A 1 -B 1 fuck $I`;if [ "$A" != "" ]; \
then printf "$I \n$A \n\n"; fi ;done|less
houghi
<snip kernel stuff>
When I see al that, those are basicaly all bash commands. So it should
be trivaial to put them in a script, put that online and tell everybody
to run that.
> If you can't boot from hard disk in order to restore the kernel, simply
> boot the system from CD/DVD. I've done so countless times.
The fact that you have rebooted from CD/DVD countless times tells me
that compiling a kernel is not that trivial. Perhaps you should have a
fallback in your grub. e.g. when a kernel does not come up, it falls
back on the default.
> Yes, there are reasons. The user shouldn't be concerned too much about
> the reasons openSUSE has to offer a slow kernel though.
I know, that is why I keep pointing to the factory mailinglist. ;-)
> And besides, using Linux without ever having build the kernel by
> yourself is lame :D
Oh, I have build kernels. I just never had a working one. :-D
houghi
> Btw, this assumes that all machines use the same type of CPU (all of
> them P4, all of them Core 2, etc.) If not, you will have to configure
> the kernel for a "generic" CPU, or take the time and compile the kernel
> on each machine individually.
Hey, perhaps that is why openSUSE has such a 'slow' kernel. Because they
have to think about each and every situation. :-D
Vahis
> Vahis wrote:
>> I wonder what will happen the next time there is a kernel patch available.
>
> Nothing. As with all software. Either you let openSUSE handle it, or you
> handle it. The kernel yu run now isn't the concern of openSUSE anymore.
>
> Be glad that it is that way. Imagine that you have edited the kernel in
> such a way that a certain part had changed sourcecode. The reason might
> be that it doesn't run your specific hardware otherwise.
>
> Now imagine that just that part is updated. You get the update and now
> your software does not work anymore.
>
> The same goes for any software. Once you compiled it yourself, YOU are
> responsible for updates and not YOU. ;-)
>
> houghi
Next time when I will see a kernel update available I can of course
install that with YaST. Then I'm back on the openSUSE default kernel.
I could go back right now by just installing the kernel and sources from
the main tree, too.
This was encouraging, though. I know now that some time in the future I
will have another trick to try in case of some jazz I can't fix in any
other way.
Vahis
--
See, mom, I'm running my own kernel!
Nikos Chantziaras
>> And besides, using Linux without ever having build the kernel by
>> yourself is lame :D
>
> Oh, I have build kernels. I just never had a working one. :-D
I just downloaded the Intel C++ 10.1 compiler directly from Intel (they
provide it free of charge for non-commercial use; free beer). I will
try to build the kernel with that one as benchmarks claim it produces
30% faster code compared to GCC (and GCC 4.2 doesn't even target Intel
Core 2)...
Yes, I am crazy ;P
Nikos Chantziaras
> On Wed, 7 Nov 2007 08:18:47 +0100, houghi <hou...@houghi.org.invalid> wrote:
>
>> Nikos Chantziaras wrote:
>>> Btw, this assumes that all machines use the same type of CPU (all of
>>> them P4, all of them Core 2, etc.) If not, you will have to configure
>>> the kernel for a "generic" CPU, or take the time and compile the kernel
>>> on each machine individually.
>> Hey, perhaps that is why openSUSE has such a 'slow' kernel. Because they
>> have to think about each and every situation. :-D
>>
>> houghi
>
> Perhaps that's why they prefer CONFIG_HZ=250 for slower CPUs.
Actually that ones depends on what you do. If you're not into stuff
that requires very exact timing (realtime 3D games, multimedia
authoring), even 100Hz is a fine value. 100 has been used for ages as
default before Linus switched to 1000 (and later to 250).
> And CONFIG_CC_OPTIMIZE_FOR_SIZE=y for ones with small hard disks.
We're talking about a difference of maybe 500kB for the kernel, and
maybe 5MB for all the modules, so that doesn't sound like a good reason :P
> And CONFIG_DEBUG_KERNEL=y for those who would like to debug the kernel and send
> bug reports?
I think this one has a different purpose; could be that openSUSE needs
some of the debug interfaces/backdoors/hooks into the kernel to monitor
stuff? (I disabled all debug switches with and didn't notice any error
messages in the logs, btw.)
Nikos Chantziaras
> Vahis wrote:
>> I wonder what will happen the next time there is a kernel patch available.
>
> Nothing. As with all software. Either you let openSUSE handle it, or you
> handle it. The kernel yu run now isn't the concern of openSUSE anymore.
>
> Be glad that it is that way. Imagine that you have edited the kernel in
> such a way that a certain part had changed sourcecode. The reason might
> be that it doesn't run your specific hardware otherwise.
>
> Now imagine that just that part is updated. You get the update and now
> your software does not work anymore.
>
> The same goes for any software. Once you compiled it yourself, YOU are
> responsible for updates and not YOU. ;-)
Good post, but wrong.
The updater is updating and replacing my custom built kernel as I'm
writing this. As I suspected, the full thing is downloaded since deltas
aren't applicable, and installed over the current one, deleting any
trace of the old kernel (including deletion of the whole
/lib/modules-version and /usr/src/linux-version directories).
Vahis
> houghi wrote:
>> Vahis wrote:
>>> I wonder what will happen the next time there is a kernel patch available.
>> Nothing. As with all software. Either you let openSUSE handle it, or you
>> handle it. The kernel yu run now isn't the concern of openSUSE anymore.
>>
>> Be glad that it is that way. Imagine that you have edited the kernel in
>> such a way that a certain part had changed sourcecode. The reason might
>> be that it doesn't run your specific hardware otherwise.
>>
>> Now imagine that just that part is updated. You get the update and now
>> your software does not work anymore.
>>
>> The same goes for any software. Once you compiled it yourself, YOU are
>> responsible for updates and not YOU. ;-)
>>
>> houghi
>
> Next time when I will see a kernel update available I can of course
> install that with YaST. Then I'm back on the openSUSE default kernel.
That happened sooner than I expected :)
>
> I could go back right now by just installing the kernel and sources from
> the main tree, too.
>
> This was encouraging, though. I know now that some time in the future I
> will have another trick to try in case of some jazz I can't fix in any
> other way.
I added a hard disk while I was running my own kernel.
YaST Partitioner failed in formatting it.
Then the new kernel version just happened to show up in the updates :)
I installed it.
The partitioner worked like charm, as it always had before :)
I'll stick with the official kernels from now on.