Hi,
Here is something that might be interesting: http://www.improvedsource.com/view.php/Linux-System/2/
Why would not Fedora developpers pull some ideas from it to faster and faster the boot time?
mihamina.rakotomandimby@etu.univ-orleans.fr (Rakotomandimby Mihamina) writes:
Here is something that might be interesting: http://www.improvedsource.com/view.php/Linux-System/2/
Why would not Fedora developpers pull some ideas from it to faster and faster the boot time?
You won't get much improvements when you stay at the old, non-parallel bash-scripts from 'initscripts'. 'initng' is a much better approach and is used by some mainstream distributions (Gentoo, perhaps Debian/Ubuntu) already and Fedora Core developers are positive to the idea to bring it into Fedora Core too.
So, it would be better to help to improve it and fix remaining issues (x86_64) in the current FE review[1]
Enrico
Footnotes: [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459
On 12/18/05, Rakotomandimby Mihamina mihamina.rakotomandimby@etu.univ-orleans.fr wrote:
Hi,
Here is something that might be interesting: http://www.improvedsource.com/view.php/Linux-System/2/
Why would not Fedora developpers pull some ideas from it to faster and faster the boot time?
Exactly which ideas do you think are worthwhile for default configurations that Fedora developers should spent some time looking at? I honestly don't see much in the way of generally applicable speed-up ideas.
Recompiling of modules into the kernel... which modules are needed to be compiled in is dependant on the system... there is no general solution here that can be applied by default and benefit "most" systems.
Tuning which services are running... has no general solution. Whether or not someone needs specific services running is a system by system determination.
Turning off auditd and selinux... not going to happen Turning off kudzu completely... not going to happen
early-login was under development by Fedora developers, so clearly the Fedora developers have been putting some time thinking about using early-login and have decided its not ready for mainstream use yet.
-jef
On Sun, Dec 18, 2005 at 12:40:57PM -0500, Jeff Spaleta wrote:
Recompiling of modules into the kernel... which modules are needed to be compiled in is dependant on the system... there is no general solution here that can be applied by default and benefit "most" systems.
If the modules aren't needed, they also won't be loaded. Any performance gains he saw was likely due to..
"Removed Selinux and auditing system calls feature"
although I'm sceptical that was responsible for a 7 second speedup.
Dave
On 12/18/05, Dave Jones davej@redhat.com wrote:
If the modules aren't needed, they also won't be loaded. Any performance gains he saw was likely due to..
"Removed Selinux and auditing system calls feature"
although I'm sceptical that was responsible for a 7 second speedup.
Yes.. the fact that he rolled several changes into one step... irks me. And there was no effort to do repeated runs to get a sense of repeatability of the timed numbers.
-jef
On Sun, 2005-12-18 at 16:16 -0500, Dave Jones wrote:
"Removed Selinux and auditing system calls feature"
although I'm sceptical that was responsible for a 7 second speedup.
Given the current extremely broken default of actually _enabling_ auditing on a rawhide install, 7 seconds wouldn't shock me so much.
We really shouldn't be running auditd and enabling syscall auditing on a default install. In fact, I think auditd itself ought to be in Extras if it's in Fedora at all.
On Sun, Dec 18, 2005 at 09:28:12PM +0000, David Woodhouse wrote:
On Sun, 2005-12-18 at 16:16 -0500, Dave Jones wrote:
"Removed Selinux and auditing system calls feature"
although I'm sceptical that was responsible for a 7 second speedup.
Given the current extremely broken default of actually _enabling_ auditing on a rawhide install, 7 seconds wouldn't shock me so much.
We really shouldn't be running auditd and enabling syscall auditing on a default install. In fact, I think auditd itself ought to be in Extras if it's in Fedora at all.
audit is currently listed within the core packages in comps.xml. Removing it from there should also be possible. Or disabling the startup by default.
I still think audit belongs into core.
regards,
Florian La Roche
Florian La Roche wrote:
On Sun, Dec 18, 2005 at 09:28:12PM +0000, David Woodhouse wrote:
On Sun, 2005-12-18 at 16:16 -0500, Dave Jones wrote:
"Removed Selinux and auditing system calls feature"
although I'm sceptical that was responsible for a 7 second speedup.
Given the current extremely broken default of actually _enabling_ auditing on a rawhide install, 7 seconds wouldn't shock me so much.
We really shouldn't be running auditd and enabling syscall auditing on a default install. In fact, I think auditd itself ought to be in Extras if it's in Fedora at all.
audit is currently listed within the core packages in comps.xml. Removing it from there should also be possible. Or disabling the startup by default.
I still think audit belongs into core.
Maybe but it still needs to be disabled by default if its going to continue having a significant impact on boot up time and general performance. I dont think audit is something Fedora users are interested in general. If we need to iron out wrinkles we can enable it only during the test/development releases.
regards Rahul
On Mon, Dec 19, 2005 at 05:51:20PM +0530, Rahul Sundaram wrote:
audit is currently listed within the core packages in comps.xml. Removing it from there should also be possible. Or disabling the startup by default.
I still think audit belongs into core.
Maybe but it still needs to be disabled by default if its going to continue having a significant impact on boot up time and general performance. I dont think audit is something Fedora users are interested in general. If we need to iron out wrinkles we can enable it only during the test/development releases.
audit has the potential to be useful though. It could be used to dynamically generate readahead.files Addition of extra services would need nothing to be changed, they'd get picked up on next boot, and added to the filelist, for speeding up subsequent boots.
Dave
Dave Jones wrote:
On Mon, Dec 19, 2005 at 05:51:20PM +0530, Rahul Sundaram wrote:
audit is currently listed within the core packages in comps.xml. Removing it from there should also be possible. Or disabling the startup by default.
I still think audit belongs into core.
Maybe but it still needs to be disabled by default if its going to continue having a significant impact on boot up time and general performance. I dont think audit is something Fedora users are interested in general. If we need to iron out wrinkles we can enable it only during the test/development releases.
audit has the potential to be useful though. It could be used to dynamically generate readahead.files Addition of extra services would need nothing to be changed, they'd get picked up on next boot, and added to the filelist, for speeding up subsequent boots.
Have you looked at preload ( http://fedoraproject.org/wiki/FedoraBounties)?
regards Rahul
Given the current extremely broken default of actually _enabling_ auditing on a rawhide install, 7 seconds wouldn't shock me so much.
Audit is enabled by default for rawhide to find bugs. It has successfully found bugs by being enabled by default. When FC5 gets close to finishing up development work, I'll disable it by default.
We really shouldn't be running auditd and enabling syscall auditing on a default install. In fact, I think auditd itself ought to be in Extras if it's in Fedora at all.
The audit system is required for any troubleshooting of SE Linux.
There is a bugzilla opened to address changes to improve performance. I'm certain speed improvements can be made.
-Steve
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Here is something that might be interesting: http://www.improvedsource.com/view.php/Linux-System/2/
Exactly which ideas do you think are worthwhile for default configurations that Fedora developers should spent some time looking at? I honestly don't see much in the way of generally applicable speed-up ideas.
I dont really know. I found that document, I just shared what I found... I am not developper, but I use FC4 on my notebook (no dual boot). Booting the fastest would insterest me, and I just brought some ideas... :-)
Rakotomandimby Mihamina wrote:
Here is something that might be interesting: http://www.improvedsource.com/view.php/Linux-System/2/
Exactly which ideas do you think are worthwhile for default configurations that Fedora developers should spent some time looking at? I honestly don't see much in the way of generally applicable speed-up ideas.
I dont really know. I found that document, I just shared what I found... I am not developper, but I use FC4 on my notebook (no dual boot). Booting the fastest would insterest me, and I just brought some ideas... :-)
Yep. Thank you for your interest. However the above link isnt much useful for that. If you havent noticed yet the whole bootchart program (http://bootchart.sf.net) came out of a challenge in Fedora to reduce boot up time and it did have a good impact on FC4. As others have pointed out this is a ongoing effort.
regards Rahul
Hi,
I dont really know. I found that document, I just shared what I found... I am not developper, but I use FC4 on my notebook (no dual boot). Booting the fastest would insterest me, and I just brought some ideas... :-)
I'm curious that people would be worried about boot times when it's much faster to suspend and resume. I use a notebook every day but only reboot when there's a new kernel or something has gone badly wrong.
Is it the case that released Fedora support for notebook features is lacking? (cf. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169201)
-Cam
On Mon, 2005-12-19 at 13:42 +0000, Cam wrote:
I'm curious that people would be worried about boot times when it's much faster to suspend and resume. I use a notebook every day but only reboot when there's a new kernel or something has gone badly wrong.
Swapping batteries. Rebooting into another OS. Booting to a new kernel.
There are many reasons why a full boot will be done.
On Mon, 2005-12-19 at 08:05 -0800, Jesse Keating wrote:
On Mon, 2005-12-19 at 13:42 +0000, Cam wrote:
I'm curious that people would be worried about boot times when it's much faster to suspend and resume. I use a notebook every day but only reboot when there's a new kernel or something has gone badly wrong.
Swapping batteries. Rebooting into another OS. Booting to a new kernel.
There are many reasons why a full boot will be done.
--
Umm... I rarely boot my machines (once in a couple of months), but I'd venture to guess that if suspend-resume was bullet-proof, people would have rebooted their machine only in the cases above, which are pretty rare events for most Linux users. Plus, I might be wrong here, but doesn't suspend to disk theoretically allows you to suspend, switch to Windows (*spit!), and pick up where you left once you switch back to Linux?
Gilboa
On Mon, Dec 19, 2005 at 06:13:27PM +0200, Gilboa Davara wrote:
Umm... I rarely boot my machines (once in a couple of months), but I'd venture to guess that if suspend-resume was bullet-proof, people would have rebooted their machine only in the cases above, which are pretty rare events for most Linux users. Plus, I might be wrong here, but doesn't suspend to disk theoretically allows you to suspend, switch to Windows (*spit!), and pick up where you left once you switch back to Linux?
As long as windows leaves the Linux partitions alone that should work.
On Mon, 2005-12-19 at 17:21 +0100, Ralf Ertzinger wrote:
On Mon, Dec 19, 2005 at 06:13:27PM +0200, Gilboa Davara wrote:
Umm... I rarely boot my machines (once in a couple of months), but I'd venture to guess that if suspend-resume was bullet-proof, people would have rebooted their machine only in the cases above, which are pretty rare events for most Linux users. Plus, I might be wrong here, but doesn't suspend to disk theoretically allows you to suspend, switch to Windows (*spit!), and pick up where you left once you switch back to Linux?
As long as windows leaves the Linux partitions alone that should work.
I can confirm that this works. You can even suspend (hibernate) in Windows as well :-)
Keith.
On Mon, 2005-12-19 at 17:21 +0100, Ralf Ertzinger wrote:
Plus, I might be wrong here, but doesn't suspend to disk theoretically allows you to suspend, switch to Windows (*spit!), and pick up where you left once you switch back to Linux?
As long as windows leaves the Linux partitions alone that should work.
And if Linux leaves the Windows partitions alone.
Gilboa Davara wrote:
Umm... I rarely boot my machines (once in a couple of months), but I'd venture to guess that if suspend-resume was bullet-proof, people would have rebooted their machine only in the cases above, which are pretty rare events for most Linux users.
My point exactly. IF you just want to pull the machine out of the bag, open it and use it, then close it and replace it, working ACPI suspend is the perfect solution. Booting becomes a relatively rare event and time to boot is less significant.
Plus, I might be wrong here, but doesn't suspend to disk theoretically allows you to suspend, switch to Windows (*spit!), and pick up where you left once you switch back to Linux?
Probably - I use ACPI suspend to RAM, I haven't tried the suspend2 (to disk) but I imagine it's slower.
If I wanted to use the other OS it's easier for me to use a vmware image than reboot.
-Cam