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 > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
