On Thu, Mar 21, 2013 at 8:52 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi....
On Thu, Mar 21, 2013 at 4:37 PM, Raymond Jennings <shentino@gmail.com> wrote:
At any rate I suppose the best way to get started on this is to get a grip on the api's involved in receiving requests from above and dispatching them below. Is studying the deadline scheduler a good start or would I be better off looking at documentation?
Valdis already gave you great feedback, so I'll just add that what you need is lots of experiments.
Oh I already agree with Valdis's feedback, and especially the concept of this not being as simple as one would hope. Before I get close to considering submitting my work upstream I'll be playing with it a lot. Mostly I want to get a grip on the brass tacks of interfacing properly with the code layers above and below my scheduler. Hence my question on the best way to learn the ropes of actually handling the requests. My goal in writing this was more to get practice writing kernel code and properly interfacing iwth other subsystems than to actually write a decent scheduler ^^.
Reading your detailed proposal, sounds like what you're doing is much similar to Con Kolivas old- Staircase scheduler (a process scheduler). The difference is, you're implementing it on disk which has way bigger latency to consider. But again, IMHO there is nothing to stop you from experimenting.
So I suggest, maybe you need to add something that anticipatory does, wait for few moments to anticipate I/O coming in nearby sectors. You need to define the limit of "nearby". If nothing coming, just keep moving. If there is one, service them while changing the "service path".
Just my 2 cents idea......
Quite, quite. Wonderful feedback everyone. At this point it's time to get my feet wet so all I'm after right now is
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com