Re: Anticipatory disk scheduling - soc 2008

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I thought of exactly the same thing (except I was not sure where to
:add this)since I assume that the scheduler which I write should be
:accessbile as an interface (hence add an API) rather than plugging it
:into the NATA driver. However this would require me to modify (would
:it?) calls in the nata code - is this OK?

    Yes.  In fact, it makes it easier because you can create a kernel option
    for your scheduler and instead of replacing the NATA code you can
    conditionalize it.

    The way that works is you add your option name to
    /usr/src/sys/conf/options and specify an option header file to include,
    such as this:

	DISKSCHED_THACKER	opt_disksched.h

    Then in the NATA driver you do:

    #include "opt_disksched.h"

    ....
    #ifdef DISKSCHED_THACKER
	... calls to your API ...
    #else
	... original nata queueing code ...
    #endif

    This allows people to select which scehduler they want to use when
    they compile their kernel.

:>
:>    This would allow you to test your scheduler with a vkernel by also having
:>    the VKD driver call it (/usr/src/sys/dev/virtual/disk).
:
:Im not sure of what I understand about the vkernel. Is this a common
:feature in BSD systems or only the DragonflyBSD? Could I have more
:information (or hyperlinks) to this and how it is important or can
:help me in testing my scheduler, as you mention above.
:
:Thanks for those tips!
:Nirmal

    'man vkernel' on a DragonFly box (e.g. on your leaf account).  It is
    specific to DragonFly.  Other BSDs have to use a machine emulator.
    Using a machine emulator works too, it just isn't as convenient.

    Basically whenever you make major modifications to a kernel, simply
    rebooting into that kernel can result in a very long development
    cycle because any bug in your code is likely to crash the kernel (and
    bugs in filesystem/block-device related code can result in a corrupt
    disk, as well).  So it is best to do all major testing of such code
    in a virtual environment before trying it out on a kernel running on
    real hardware.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>