On Thu, 22.07.10 09:11, Jeff Spaleta (jspaleta(a)gmail.com) wrote:
On Thu, Jul 22, 2010 at 8:48 AM, Lennart Poettering
<mzerqung(a)0pointer.de> 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.