Re: CONFIG_IOSCHED_* in m68k kernel
On Wed, 20 May 2009, Lance Tagliapietra wrote:
> 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:
> >
> > > >
> > > > 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.
They don't need to be the same kernel. I have run the installer with
custom build kernels (with suitable drivers built-in, since those modules
on the initrd are only usable with the corresponding kernel).
> 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.
There's an argument for modular IO schedulers, but the question then is,
which one will be built in? How much IO takes place before modules become
available for loading? I expect that debian kernel devs already
deliberated this.
> 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!
As you probably found already, there's more good stuff on that wiki, like
http://elinux.org/System_Size
which shows how to measure kernel image size.
I recommend cross compiling for this kind of experimentation (or any
kernel build) since it only takes a few minutes on a typical PC.
Finn
>
> --Lance
>
> >
> > Finn
> >
> > [1] http://elinux.org/Kernel_Size_Tuning_Guide
> >
> > >
> > > Peace,
> > >
> > > Stephen
> > >
> > >
>
>
>
Reply to: