[HEADS-UP] systemd for F14 - the next steps

Lennart Poettering mzerqung at 0pointer.de
Thu Jul 22 16:48:01 UTC 2010


On Thu, 22.07.10 10:42, Mike McGrath (mmcgrath at redhat.com) wrote:

> > how do you deal with circular dependencies in this case?
> > I mean what will happen ? Will all services just deadlock?
> > Malfunction ? Anything that guarantees correct initialization and
> > behavior ?
> 
> In addition to circular deps, have any studies been done on disk
> contention when you just start everything all at once? If we're not
> careful we could actually increase boot time in some scenarios.  I guess
> one way to check would be to go through all your init scripts and add a &
> to the end of the start line?

In theory the elevator should benefit from having more requests at the
same time to choose from. However, theory is theory, and in fact the
Linux IO scheduler does not benefit from this on rotating media too much
right now. However, I think this kind of brokenness needs to be fixed in
the kernel.

This general problem has been discussed a couple of times in the meego
community iirc. There have been suggestions to improve the
situation. But nothing so far has been compelling and actually been
fixed in the kernel.

In generally I believe the right approach is to let the kernel IO
scheduler schedule IO and not try to work around perceived brokeness
simply by always serializing things on the userspace side already. Don't
try to second-guess the IO scheduler, fix it.

One could say that the IO scheduler is currently not directly optimized
for this kind of IO load, because this load simply didn't exist
before. It needs more optimization in this area.

There have been attempts to work around this problem in userspace. For
example with stuff like readahead. I personally believe that readahead
is a deadend, and a correct fix for the problem would be more akin to
Axboe's fcache, i.e. in order to optimize access time it is better to
rearrange sectors then simply reading them in a different order and
hoping this doesn't interfere with the normal IO scheduling applied.

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.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list