Re: CONFIG_IOSCHED_* in m68k kernel
On Tue, 19 May 2009, Stephen R Marenka wrote:
> On Tue, May 19, 2009 at 06:28:51PM -0500, Lance Tagliapietra wrote:
> > Hello,
> >
> > I have observed that the m68k kernels available from [1] seem to have all the
> > I/O Schedulers selected. In other words all CONFIG_IOSCHED are being built
> > in to the kernel (at least in the 2.6.26 and 2.6.28 available for the Amiga
> > that I checked). For example:
> >
> > #
> > # IO Schedulers
> > #
> > CONFIG_IOSCHED_NOOP=y
> > CONFIG_IOSCHED_AS=y
> > CONFIG_IOSCHED_DEADLINE=y
> > CONFIG_IOSCHED_CFQ=y
> > # CONFIG_DEFAULT_AS is not set
> > # CONFIG_DEFAULT_DEADLINE is not set
> > CONFIG_DEFAULT_CFQ=y
> > # CONFIG_DEFAULT_NOOP is not set
> > CONFIG_DEFAULT_IOSCHED="cfq"
> >
> > I have done some checking, and have found that:
> > a) CONFIG_IOSCHED_NOOP uses the least amount of RAM.
> > b) CONFIG_IOSCHED_DEADLINE is the next
> > c) CONFIG_IOSCHED_AS and CONFIG_IOSCHED_CFQ are about the same and
> > more than NOOP or DEADLINE.
> > d) The kernel default for m68k is CONFIG_DEFAULT_AS=y (per 2.6.29.1).
> >
> > Is there a reason why all three are being built in to the m68k installer kernels?
> > After some checking [2, among others] and testing, I would suggest the following:
> >
> > #
> > # IO Schedulers
> > #
> > CONFIG_IOSCHED_NOOP=y
> > # CONFIG_IOSCHED_AS is not set
> > # CONFIG_IOSCHED_DEADLINE is not set
> > # CONFIG_IOSCHED_CFQ is not set
> > # CONFIG_DEFAULT_AS is not set
> > # CONFIG_DEFAULT_DEADLINE is not set
> > # CONFIG_DEFAULT_CFQ is not set
> > CONFIG_DEFAULT_NOOP=y
> > CONFIG_DEFAULT_IOSCHED="noop"
No-op is meant for devices with large caches and built-in elevators, like
hardware RAID arrays, and for storage with no need for any elevator, like
flash. On plain old rotating storage I'd expect performance would suffer
with no-op.
Having all the IO schedulers in the debian kernel makes it is easy to
benchmark the performance of the alternatives on my particular hardware
before I choose one for a custom kernel.
> >
> > As this configuration minimizes kernel footprint, the various other
> > schedulers can be made modules with no change in the footprint, but is
> > there value in having them in the initrd for the installler?
> >
> > Thoughts?
>
> Only reason I know of is that it happens to be the Debian default. If
> other folks think it's worthwhile I can change this for m68k and see if
> Debian wants to change it for all archs.
For most users, no single default setting would be sufficient to remove
the benefit of a custom kernel (tailored to a particular machine and its
purpose). So I doubt that this approach could save us from the chore of
compiling kernels for RAM constrained systems. Especially if we wanted
say, linux-tiny patches [1].
Finn
[1] http://elinux.org/Kernel_Size_Tuning_Guide
>
> Peace,
>
> Stephen
>
>
Reply to: