On Thu, Aug 21, 2008 at 07:33:34PM +1000, Nick Piggin wrote: > > > But existing plugging is below the level of the elevators, and should > > > only kick in for at most tens of ms at queue idle events, so it sounds > > > like it may not be your problem. Elevators will need some hint to give > > > priority to specific requests -- either via the current threads's io > > > priority, or information attached to bios. > > > > It's getting too bloody complex, IMO. What is right for one elevator > > is wrong for another, so as a filesystem developer I have to pick > > one to target. > > 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... > > 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? > > 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..... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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