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?
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 <[email protected]>
SUSE Labs, CR
2013/10/23 Jan Kara <[email protected]>:
> 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 <[email protected]>
> 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.
On Wed, Oct 23, 2013 at 6:59 PM, Jan Kara <[email protected]> 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
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 <[email protected]>:
> On Wed, Oct 23, 2013 at 6:59 PM, Jan Kara <[email protected]> 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
On Fri 25-10-13 11:10:22, 韩磊 wrote:
> 2013/10/23 Jan Kara <[email protected]>:
> > 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 <[email protected]>
> > 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 <[email protected]>
SUSE Labs, CR