[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: Corrado Zoccolo <czoccolo gmail com>
- To: Jeff Moyer <jmoyer redhat com>
- Cc: dhaval linux vnet ibm com, peterz infradead org, dm-devel redhat com, dpshah google com, Jens Axboe <jens axboe oracle 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, 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: Mon, 5 Oct 2009 23:09:21 +0200
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?
Thanks,
Corrado
>
> Cheers,
> Jeff
>
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]