On Thu, 22.07.10 09:11, Jeff Spaleta (jspaleta@xxxxxxxxx) wrote: > > On Thu, Jul 22, 2010 at 8:48 AM, Lennart Poettering > <mzerqung@xxxxxxxxxxx> wrote: > > Looking at what Windows and MacOS do in this area is probably > > healthy. Both systems rearrange sectors on disk and parallelize as much > > as possible. I think that's bascially a good recipe we should follow > > too. systemd caters for the latter, we need kernel fixes to cater for > > the former. > > Have you had some discussions with people who have a good > understanding of the kernel I/O scheduler about looking at this work > load as an optimization target? There were some discussions at LPC last year. It is my intention to talk about this at LPC again, this time with a clear focus on the realistic workload systemd actually generates. (Kay Sievers and I will do a presentation about systemd there). Some folks in the kernel community tend to argue that the problem slowly goes away with introduction of SSD anyway, but I personally think that rotating media is going to stay long enough with us that it would be worth fixing boot. > Also, thinking worse case scenario. If in the rawhide runup if the > release management team find the disk I/O scheduling is a significant > problem when many of our default services "go native." Would it be a > reasonable fallback to flip back some of the services to sysinit style > scripts by default? I'm not suggesting it will be a significant > problem (nor am I putting my neck out and defining what significant > means here...) but its good to have an understanding of where rough > edges are anticipated and to have a fallback plan if the kernel > scheduling can't get fixed in the pre F14 time scale. Well, the worst that happens right now is that the boot up isn't really faster with systemd than without systemd on rotating media. I see little reason to reverse any changes if that's the worst that happens. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
