Re: Anticipatory disk scheduling - soc 2008

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hello,
:
:This is concerning the soc 2008 project for anticipatory disk
:scheduling . My mentor (Simon) has pointed me to the current scheduler
:in the code. I am sending this mail , however to find out more
:details. I could be digging through the code as well but if some of
:you out there already know what exists it would be great to understand
:a little more so that i can dig in the right places.
:
:The current scheduler lies in the src/sys/dev/disk/nata/ata-queue.c
:file . Are there any more related files? I did go through the
:dev/disk/nata code and I didn't seem to find other related pieces of
:code
:
:This seems like a simple elevator scheduler . Would you like the
:anticipatory disk scheduler to reside here as well?
:
:Could there be some similar documentation with FreeBSD - what kind of
:scheduler does FreeBSD implement? Would a cross reference code to
:FreeBSD be available? (something like LXR)
:
:Any more ideas/suggestions?
:
:Hopefully by this week, I'd like to understand requirements for the
:concerned people and make a brief design before I start from the 26th.
:
:Thanks!
:Nirmal

    I'm not sure what FreeBSD does.  Note that our NATA code is a direct
    port from FreeBSD's ata driver so I expect they may be using the same
    scheduler, though there could be something up in a higher GEOM layer
    as well.

    In anycase, you've nailed the location of the current scheduler.

    What I recommend is that you not implement your anticipitory scheduler
    in the NATA driver.  Instead, create an API in /usr/src/sys/kern/ that
    implements the feature and then just NATA to call the API instead of
    rolling its own elevator algorithm.

    e.g. create a /usr/src/sys/kern/subr_disksched.c source file, put the
    API and scheduler support in there.  Then have NATA call it.

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

    There are some other issues that will probably crop up, not the least
    of which is going to be how to manage the buffer cache to provide
    buffers you can run your anticipatory actions on.  High level filesystems
    such as UFS already do some degree of clustering, but they do it at
    a higher logical level that does not translate easily.

    The most important thing to do when starting up is to get a virtual
    kernel setup going so you don't crash the real machine (or your real
    disk device... you could end up with a non-working machine!) during
    basic development.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>