A thought about IO scheduler in linux kernel for SSD

A thought about IO scheduler in linux kernel for SSD

[韩磊]

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?

A thought about IO scheduler in linux kernel for SSD

[韩磊]

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?

A thought about IO scheduler in linux kernel for SSD

[韩磊]

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?

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

[Jan Kara]

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@suse.cz>
SUSE Labs, CR

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

[韩磊]

2013/10/23 Jan Kara <jack@suse.cz>:
> 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.
>
>   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@suse.cz>
> SUSE Labs, CR

Do you mean that the probability of two bios have the same start
sector in request list at this level is very low??Discuss with you
is a kind of enjoyment.

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

[Jan Kara]

On Fri 25-10-13 11:10:22, 韩磊 wrote:
> 2013/10/23 Jan Kara <jack@suse.cz>:
> > 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.
> >
> >   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@suse.cz>
> > SUSE Labs, CR
> 
> Do you mean that the probability of two bios have the same start
> sector in request list at this level is very low?
  Yes, that's exactly what I mean. As Ming Lei notes, there are ways how it
could happen (most notably any direct IO user can generate arbitrary number
of bios with the same start sectors). But in none of these cases
performance matters, it is usually a bug in application if that happens.

							Bye
								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

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

[Ming Lei]

On Wed, Oct 23, 2013 at 6:59 PM, Jan Kara <jack@suse.cz> wrote:
> 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.

The situation might be triggered when same file is read from two tasks,
one is read via page cache, and another one is read by O_DIRECT.

But still not sure if that makes sense.

Thanks,
-- 
Ming Lei

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

[韩磊]

Thanks for your thought!  It may not make much sense. Because I think
the probability of two bios have the same start sector and the
situation mentioned by Ming Lei is too low.
Thanks ,
Bonben

2013/10/25 Ming Lei <tom.leiming@gmail.com>:
> On Wed, Oct 23, 2013 at 6:59 PM, Jan Kara <jack@suse.cz> wrote:
>> 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.
>
> The situation might be triggered when same file is read from two tasks,
> one is read via page cache, and another one is read by O_DIRECT.
>
> But still not sure if that makes sense.
>
> Thanks,
> --
> Ming Lei