On Friday 22 August 2008 03:08, Dave Chinner wrote: > On Thu, Aug 21, 2008 at 07:33:34PM +1000, Nick Piggin wrote: > > I don't really see it as too complex. If you know how you want the > > request to be handled, then it should be possible to implement. > > That is the problem in a nutshell. Nobody can keep up with all > the shiny new stuff that is being implemented,let alone the > subtle behavioural differences that accumulate through such > change... I'm not sure exactly what you mean.. I certainly have not been keeping up with all the changes here as I'm spending most of my time on other things lately... But from what I see, you've got a fairly good handle on analysing the elevator behaviour (if only the end result). So if you were to tell Jens that "these blocks" need more priority, or not to contribute to a process's usage quota, etc. then I'm sure improvements could be made. Or am I completely misunderstanding you? :) > > > With the way the elevators have been regressing, > > > improving and changing behaviour, > > > > AFAIK deadline, AS, and noop haven't significantly changed for years. > > Yet they've regularly shown performance regressions because other > stuff has been changing around them, right? Is this rhetorical? Because I don't see how *they* could be showing regular performance regressions. Deadline literally had its last behaviour change nearly a year ago, and before that was before recorded (git) history. AS hasn't changed much more frequently, although I will grant that it and CFS add a lot more complexity. So I would always compare results with deadline or noop. > > > I am starting to think that I > > > should be picking the noop scheduler. > > > Any 'advanced' scheduler that > > > is slower than the same test on the noop scheduler needs fixing... > > > > I disagree. On devices with no seek penalty or their own queueing, > > noop is often the best choice. Same for specialized apps that do > > their own disk scheduling. > > A filesystem is nothing but a complex disk scheduler that > has to handle vastly larger queues than an elevator. Іf the > filesystem doesn't get it's disk scheduling right, then the > elevator is irrelevant because nothing will fix the I/O > problems in the filesystem algorithms..... I wouldn't say it is so black and white if you have multiple processes submitting IO. You get more opportunities to sort and merge things in the disk scheduler, and you can do things like fairness and anticipatory scheduling. But if XFS does enough of what you need, then by all means use noop. There is an in-kernel API to change it (although it's designed more for block devices than filesystems so it might not work exactly for you). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
