linux-kernel - Re: CFQ will be the new default IO scheduler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200607250756.49071.a1426z@gawab.com>
Date:	Tue, 25 Jul 2006 07:56:49 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: CFQ will be the new default IO scheduler - why?

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/