Re: Anticipatory disk scheduling - soc 2008

["Nirmal Thacker" <thacker.nirmal@xxxxxxxxx>]

On Tue, May 20, 2008 at 2:13 PM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>
> :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.

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?

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

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

Thanks for those tips!
Nirmal