linux-kernel - Re: A thought about IO scheduler in linux kernel for SSD

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20131023105931.GG1275@quack.suse.cz>
Date:	Wed, 23 Oct 2013 12:59:31 +0200
From:	Jan Kara <jack@...e.cz>
To:	韩磊 <bonben1989@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: A thought about IO scheduler in linux kernel for SSD

On Wed 23-10-13 08:47:44, 韩磊 wrote:
> Nowadays,the IO schedulers in linux kernel have four types:
> 
> deadline,noop,Anticiptory and CFQ.CFQ is the default scheduler.But CFQ is
> not a good scheduler for SSD,dealine may be a good choice.

> When deadline runs,it has a mount of computation about merging and
> sorting.Merge has three types: front_merge,no_merge and back_merge.
> Why don't have  another type: merge based same sector.For example,it have
> two bios in a request list,theyboth have the same bi->sector,the bi->size
> maybe not equal. Whether can we put the latter bio replace the former?What
> do you find that significant?Or the other levels in OS has finished this
> function?
  That doesn't make much sense to me. If there are two bios in flight for
some sector, results are undefined. Thus we usually avoid such situation
(usually we want to have defined contents of the disk :). The exclusion is
usually achieved at higher level using page locking etc. So adding code
speeding up such requests doesn't seem worth it.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/