DragonFly kernel List (threaded) for 2008-05
DragonFly BSD
DragonFly kernel List (threaded) for 2008-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Anticipatory disk scheduling - soc 2008

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 20 May 2008 11:52:46 -0700 (PDT)

: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"

	... calls to your API ...
	... original nata queueing code ...

    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!

    '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.

					Matthew Dillon 

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