[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[dm-devel] Re: Do we support ioprio on SSDs with NCQ (Was: Re: IO scheduler based IO controller V10)
- From: Jens Axboe <jens axboe oracle com>
- To: Corrado Zoccolo <czoccolo gmail com>
- Cc: dhaval linux vnet ibm com, peterz infradead org, dm-devel redhat com, dpshah google com, agk redhat com, balbir linux vnet ibm com, paolo valente unimore it, jmarchan redhat com, fernando oss ntt co jp, Ulrich Lukas <stellplatz-nr 13a datenparkplatz de>, mikew google com, Jeff Moyer <jmoyer redhat com>, nauman google com, Ingo Molnar <mingo elte hu>, Vivek Goyal <vgoyal redhat com>, m-ikeda ds jp nec com, riel redhat com, lizf cn fujitsu com, fchecconi gmail com, Valdis Kletnieks vt edu, containers lists linux-foundation org, Mike Galbraith <efault gmx de>, linux-kernel vger kernel org, akpm linux-foundation org, righi andrea gmail com, torvalds linux-foundation org
- Subject: [dm-devel] Re: Do we support ioprio on SSDs with NCQ (Was: Re: IO scheduler based IO controller V10)
- Date: Tue, 6 Oct 2009 10:41:20 +0200
On Mon, Oct 05 2009, Corrado Zoccolo wrote:
> On Mon, Oct 5, 2009 at 5:06 PM, Jeff Moyer <jmoyer redhat com> wrote:
> > Corrado Zoccolo <czoccolo gmail com> writes:
> >
> >> Moreover, I suggest removing also the slice_resid part, since its
> >> semantics doesn't seem consistent.
> >> When computed, it is not the residency, but the remaining time slice.
> >
> > It stands for residual, not residency. Make more sense?
> It makes sense when computed, but not when used in rb_key computation.
> Why should we postpone queues that where preempted, instead of giving
> them a boost?
We should not, if it is/was working correctly, it should allow both for
increase/descrease of tree position (hence it's a long and can go
negative) to account for both over and under time.
--
Jens Axboe
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]