On Tue, Dec 19, 2006 at 02:58:07PM -0500, Jeff Garzik wrote: > 10. Boot and shutdown speedup > > Jens Axboe did some kernel work for this, fcache: > http://lkml.org/lkml/2006/5/15/46 > > A lot of the boot slowness here comes from (a) udev [10+ seconds in > startup], or (b) non-parallel initscripts. The biggest wins will come from a) do less stuff. Why are we starting so many things up during boot? Do I need to be running a smartcard daemon on a system with no smartcard reader? Do I need a bluetooth service on a system with no bluetooth? etc etc b) do less stuff. For the apps that we *do* need to start up, make them behave properly instead of opening gazillions of files pointlessly. More IO tracing work needed here to find the latest round of bad juju. (It's a different set of culprits every release). c) minimise contention. Instead of having everything competing for disk bandwidth during startup, we could have say.. cups start up, and do nothing for a while, and when the disk becomes idle, /then/ do its IO pulling in configs etc. The set_ioprio syscalls added a few kernels back may also be interesting. > 18. Move to using libata for PATA support > > Please keep me and Alan Cox in the loop on this. > > NOTE: You might need some intelligence in mkinitrd to avoid adding > spurious drivers such as pata_generic or ata_generic to the initrd, > after matching more specific pata_* drivers. That bit sounds like it could be trickier than it sounds for some reason. We decide what goes into the initrd based on PCI ID, so if that matches before the real chip driver, it could go in. And blacklisting it not to go in at all would suck for chipsets we don't (yet) have drivers for. Sounds like some black magic is needed to make sure this happens at the end. I see 'ata_generic' but no 'pata_generic'. Did you mean 'pata_legacy' perhaps? We don't build that. (and probably won't). The biggest problem we've hit so far has been the "modprobe returns before the disks are found". We need some better smarts than what we currently have which amounts to something like.. while [ 5 seconds havent passed ] did /proc/scsi/scsi change? sleep 1 done Ugly hack, but Peter has been swamped of late, so hasn't got around to doing 'the right thing' for mkinitrd. > J1) (possibly not FC7 material) installer support for a few popular > FUSE filesystems Tricky, as the filesystems need to be in the installer image. What's the use-case for this ? The only one I can think of is for the fuse crypto stuff, and a better solution for crypto installs is probably going to be to use e2cryptfs. > J2) Drop support for any hardware that does not support -march=i686 I'd really like to drop the 586 kernel, but I fear there are still far too many people with old VIA EPIA's and the like out there. At some point, I think it makes sense for a spin-off of Fedora to happen for older machines, but it really needs someone with the time and energy to make it happen. Something more feasible would be to drop support for all the ancient ISA junk. We can't reasonably debug failures in these ancient drivers any more because a lot of the time they're board specific problems. I don't even have any systems with ISA slots any more, let alone ISA cards. It's completely unsupportable, and upstream seems to care less and less about ancient stuff all the time (not just sound cards, but others too). Worse yet, people seem to expect feature parity from 10 year old hardware. There are a number of "Why doesn't udev find my ISA sound card" bugs. The only spanner in the works is that some laptops for god knows what reason, have their sound devices on ISA busses. Dave [*] I should be careful, last time I said "I don't have any ISA cards" some joker left an ISA SB16 in my cube. -- http://www.codemonkey.org.uk -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
