Re: linux deadline i/o elevator tuning

Поиск
Список
Период
Сортировка
Искать
От
Matthew Wakeling
Тема
Re: linux deadline i/o elevator tuning
Дата
Msg-id
alpine.DEB.2.00.0904091541110.4053@aragorn.flymine.org
Ответ на
Список
Дерево обсуждения
linux deadline i/o elevator tuning Mark Wong <markwkm@gmail.com>
Re: linux deadline i/o elevator tuning "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: linux deadline i/o elevator tuning Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: linux deadline i/o elevator tuning Matthew Wakeling <matthew@flymine.org>
Re: linux deadline i/o elevator tuning Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: linux deadline i/o elevator tuning "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: linux deadline i/o elevator tuning Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: linux deadline i/o elevator tuning Matthew Wakeling <matthew@flymine.org>
Re: linux deadline i/o elevator tuning "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: linux deadline i/o elevator tuning Scott Carey <scott@richrelevance.com>
Re: linux deadline i/o elevator tuning "Albe Laurenz *EXTERN*" <laurenz.albe@wien.gv.at>
Re: linux deadline i/o elevator tuning Jeff <threshar@torgo.978.org>
Re: linux deadline i/o elevator tuning "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: linux deadline i/o elevator tuning Arjen van der Meijden <acmmailing@tweakers.net>
Re: linux deadline i/o elevator tuning "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: linux deadline i/o elevator tuning Mark Wong <markwkm@gmail.com>
Re: linux deadline i/o elevator tuning Mark Wong <markwkm@gmail.com>
On Thu, 9 Apr 2009, Grzegorz Jaśkiewicz wrote:
> (btw, CFQ is the anticipatory scheduler).

No, CFQ and anticipatory are two completely different schedulers. You can 
choose between them.

>> But the anticipatory scheduler basically makes the huge assumption that you
>> have one single disc in the system that takes a long time to seek from one
>> place to another. This assumption fails on both RAID arrays and SSDs, so I'd
>> be interested to see some numbers to back that one up.
>
> So to avoid possible starvation problem, it will wait for short amount
> of time - in hope that app will want to read possibly next block on
> disc, and putting that request at the end of queue could potentially
> starve it. (that reason alone is why 2.6 linux feels so much more
> responsive).

This only actually helps if the assumptions I stated above are true. 
Anticipatory is an opportunistic scheduler - it actually witholds requests 
from the disc as you describe, in the hope that a block will be fetched 
soon right next to the last one. However, if you have more than one disc, 
then witholding requests means that you lose the ability to perform more 
than one request at once. Also, it assumes that it will take longer to 
seek to the next real request that it will for the program to issue its 
next request, which is broken on SSDs. Anticipatory attempts to increase 
performance by being unfair - it is essentially the opposite of CFQ.

Matthew

-- 
 Now you see why I said that the first seven minutes of this section will have
 you looking for the nearest brick wall to beat your head against. This is
 why I do it at the end of the lecture - so I can run.
                                        -- Computer Science lecturer
В списке pgsql-performance по дате отправления
От: Kevin Grittner
Дата:
От: Grzegorz Jaśkiewicz
Дата:
FAQ