Arjan van de Ven wrote: > > > Should there be a default scheduler per filesystem? As some > > > filesystems may perform better/worse with one over another? > > > > It's currently perDevice, and should probably be extended to perMount. > > Hi, Hi! > per mount is going to be "not funny". I assume the situation you are > aiming for is the "3 partitions on a disk, each wants its own elevator". > The way the kernel currently works is that IO requests the filesystem > does are first flattened into an IO for the entire device (eg the > partition mapping is done) and THEN the IO scheduler gets involved to > schedule the IO on a per disk basis. IC. That probably explains why concurrent io-procs have such a hard time getting through to the disk. They probably just hang in the flatting phase, waiting for something to take care of their requests. > The 2.4 kernel did this the other way around, and it was really a bad > idea (no fairness, less optimal scheduling all around due to less > visibility into what the disk is really doing, several hardware > properties such as TCQ depth that affect scheduling IOs are truely per > disk not per partition etc etc) > > So I don't think it's likely that per mount is really an option right > now.. Probably true as it stands right now, but extending io-sched semantics to be filesystem aware in the "flattening/partition mapping" phase could improve performance a lot. Thanks! -- Al - 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
