Harald Hoyer wrote: for testing an empty dir ? ;)

On Fri, Jun 22, 2007 at 05:18:54PM +0200, Harald Hoyer wrote: > Hello, > > some of you may have read some wiki pages about the plans for the new init system [1]. As a first step in > this direction [2], I packaged prcsys from Mandriva, patched initscripts with a very small patch, and uploaded > the src.rpm to [3]. To enable parallel booting just build and install both packages and edit > /etc/sysconfig/init. Set PARALLEL_STARTUP=yes and there we go. > > The next step would be to modify all initscripts in /etc/init.d to be LSB compliant [4]. This will speed up > booting, because they can and will be started in parallel. You should file bugzillas against the component, to > which this initscript belongs, with a patch (this has to be done anyway to be LSB compliant in regards to > initscripts over time). Especially the exit codes need to be fixed (which will make status queries a lot > easier and more robust). > > Early login [5] is also a next step towards a "fast boot" user experience. > > Alternatives to SysVInit (like upstart/initng) can live in Fedora as well, but we are very conservative in > changing the startup mechanism that proved to function for a long time now. Unless the "real" killer feature > is absolutly needed, we would like to keep backwards compatibility as long as possible. > > I hope many of you try and test [3] and write patches to improve our service initscripts to be LSB compliant > :-) Parallel booting is the reward. > > Happy testing, > Harald > > [1] http://fedoraproject.org/wiki/FCNewInit > [2] http://fedoraproject.org/wiki/FCNewInit/RC > [3] http://people.redhat.com/harald/downloads/initscripts/parallel/ > [4] http://fedoraproject.org/wiki/FCNewInit/Initscripts > [5] http://fedoraproject.org/wiki/FCNewInit/xdm >

Ville Skyttä wrote : Ouch! As much as the new approach seems interesting, I always remove the redhat-lsb package from my minimal installs because of all the useless (in my case) X related packages it pulls in :-/ BTW, is this just some initial test? Or will Fedora officially move in this direction, with the change discussed and approved by FESCO? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.21 0.34 0.40

Bill Nottingham (notting(a)redhat.com) said: Not seeing any other benchmarks, I decided to test this. Fairly standard box - P4, ata_piix, 1G memory. Stock desktop install, fully up to date with updates and updates-testing as of this afternoon. A 'normal' boot to gdm is about 56.9 seconds. I installed prcsys, and edited the startup scripts to add LSB dependencies as attached. I then booted with prcsys and parallel init. The new boot time was... 56.3 and 56.6 seconds. So, for all this work, we get a 0.6%-1.1% speedup. Oh, and we get 62 AVCs from SELinux in the process. What's the point of this again? I also don't see how it handles either of these. Bill

Bill Nottingham <notting <at> redhat.com> writes: Yeah, not very useful it would seem... What happened to this? http://fedoraproject.org/wiki/FCNewInit/xdm Is it being worked on? (Yeah, I know - I should probably not ask questions, but submit patches :-) the time they type in/pick the username and password, other stuff would have already started in the background, but the "boot time" would appear shorter. Isn't that the trick used on Windaz boxes as well? -- Bojan

On Wed, 2007-07-04 at 02:32 +0000, Bojan Smojver wrote: Possibly, but I think the biggest speedup by far is the disk caching/reorganization that both Windows and OS X do: http://www.kernelthread.com/mac/apme/optimizations/ At this rate though, we might all be using solid state drives before the kernel developers stop pointing at userspace as the problem and implement it for Linux.

On Fri, Jul 06, 2007 at 04:03:09PM -0500, Jason L Tibbitts III wrote: If you run the system entirely from a giant RAM disk (eg a gigabyte i-RAM) you'll rapidly discover that the disk isn't the biggest bottleneck Disk performance is usually quantified in ops/second. If you read linear data you'll get 57MB/sec. Go to true random access and performance is way way lower and hasn't improved much in the past ten years. Alan

On Fri, Jul 06, 2007 at 08:26:07PM -0500, Jason L Tibbitts III wrote: it does appear to be significant like big software builds but booting is other load

On 7/6/07, Alan Cox <alan(a)redhat.com&gt; wrote: Speaking from my many days as a performance analyst, Pfeifer's first rule of performance says "The only good I/O is one you don't do". I'll second Alan here. The OS can mitigate the effects of I/O but userspace has the onus to be reasonable. darrell

On Fri, Jul 06, 2007 at 05:56:35PM -0400, Colin Walters wrote: Quite a bit in terms of the disk layer. We readahead and writebehind, we preallocate data so that trickling writes don't end up smeared around the disk Try running FC7 off a Gigabyte i-RAM (you'll need the approved RAM and a recent firmware for it to be reliable). You can then seperate the disk and non-disk load Hooray, and I hope mapped shared across all users. Yes. There are things we can do such as better predicting what I/O is coming and what data not to write yet (and when to defer writing for reading). There are things we can't do like make the old gconf one key per file implementation not suck. Which is good. One area that probably could do with more work (although openoffice has forced many improvements ;)) is the linker and ELF loader side, both from the user space point of view for performance, and the kernel point of view to reduce page fault counts and between the two of them to load data in a sane order when doing demand paging (actually for large systems I question these days how useful demand paging is for most apps)

Colin Walters wrote: you can boot with "init=/sbin/readahead-collector" but for me this ended up in readahead to many files... which caused a high diskload during boot which results into a longer boot time.

Bill Nottingham schrieb: With: S12syslog S13ip6tables S13iptables S14network S25netfs S26auditd S26messagebus S27setroubleshoot S55sshd S98haldaemon S99local /etc/rc.d/rc takes: 8.5s in normal mode 6s in parallel startup so for me thats 140% speedup :) for that, I now have a fix. yep, tbd yep, tbd yep, tbd Which system does fullfill all of these requirements yet? Harald

Harald Hoyer (harald(a)redhat.com) said: Did you add all the proper dependencies? 2.5 seconds is 140%? I can try a more minimal setup, but I think we should be concentrating on the normal case. Got code? I'm interested in how much time is lost in the audit/setroubleshoot logger logging the AVCs. None, yet. But from looking at the prcsys architecture I'm not sure *how* it would do any of those - it seems to be designed in such a way to make that hard. Bill

Harald Hoyer (harald(a)redhat.com) said: Will check. That's fine... I'm just concerned about using prcsys if it doesn't actually show much benefit. Bill

On Mo Juli 9 2007, Jaroslaw Gorny wrote: You calculated the the reduction of boottime. I would calculate the speedup this way: Bootspeed = 1/(Time to boot) normal speed = 10/85 parralel startup speed = 10/60 Speedup in percent: 10/60 / 10/85 * 100 = 141.67 % Regards, Till

On Fri, 2007-06-22 at 17:18 +0200, Harald Hoyer wrote: Harald, I had a quick look over the prcsys code, here are some initial impressions - No test suite - Calls system() without checking for error - Doesn't check for $ in facility names - Doesn't differentiate between Required and Should, ie. Should is treated as a hard requirement too, which seems to violate the LSB intent - Checks for mandriva flags, X-Mandriva-Interactive, X-Mandriva-Compat-Mode - Uses the same fixed length of 256 for facility names and paths - There is a bunch of other hardcoded string lengths in there, like char file[255], this should probably be cleaned up - I regularly see "Cannot create temporary file" in --test output - Some init script output seems to go into the log file (might be related to the previous point) - It calls exit(1) a bunch - it probably shouldn't - Typo in message: "Unknow mode" - This looks sneaky, with buflen being a function parameter: char temp_dep[2][buflen]; All of this is fixable of course, this is after all just 1400 lines of code. I guess the question is if Mandriva is willing to develop this as a cross-distro project. If yes, where is the bug tracker to file bugs and patches about these problems ? If not, I don't see us winning too much by reusing 1400 lines of mediocre C code. Anyway, here are what I think are the top priorities if you want to turn this into an rc implementation suitable for Fedora and RHEL: - Add a test suite. I would expect at least tests for the parsing of the LSB headers, for the construction of the dependencies graphs, for correct serialization of the dependencies, handling of missing soft dependencies, and tests for compat mode - Implement Should - Do a thorough audit of the code and make it handle errors carefully and systematically Matthias