[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CONFIG_IOSCHED_* in m68k kernel



On Wed, May 20, 2009 at 01:58:34PM +1000, Finn Thain wrote:
> 
> 
> 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].

OK, NOOP is not the best choice for the IOSCHED, DEADLINE seems to be the 
next best in terms of footprint.  In any case, the other schedulers can
be set up as modules for performance tuning.  I have not read any traffic
on this list where such tuning was a subject of discussion.

What I am trying to get at was that the kernel used to install does not 
necessarily have to be the kernel we boot from (or does it?) after needing
the initrd.  On m68k, such a kernel does not need to be feature rich, but
needs to supply those features needed to allow install and the initrd.  As
you said, no single default kernel will remove the benefit of a custom 
kernel, and I completely agree.

Instead of supplying everything in the default, the thought was to minimize
the default (especially, the kernel+initrd to get to the first re-boot of
the install, where all the modules have been loaded on to the hard disk.

I would assume that the m68k subarches have their own kernel configs?  If
for no other reason than to select the subarch being targeted?

I have pulled a significant amount of items out of the kernel config, such
that it is using 1.7M on my 16M system.  From that exercise I came up with
several other general kernel config options that could very probably be 
turned off without effect, especially for the install kernel.  I'd be happy
to share if the group is interested.

This has a huge benefit in kernel compile time reduction. For me, this has
benefit to help with getting the clgen driver working so my EGS Spectrum
card will be useful under 2.6.

Thanks for the tuning reference!

--Lance

> 
> Finn
> 
> [1] http://elinux.org/Kernel_Size_Tuning_Guide
> 
> > 
> > Peace,
> > 
> > Stephen
> > 
> > 


Reply to: