Re: [PATCH] maximize dispatching in block throttle

[Hillf Danton]

On Mon, Dec 6, 2010 at 10:54 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> On Sat, Dec 04, 2010 at 09:36:40PM +0800, Hillf Danton wrote:
>> On Fri, Dec 3, 2010 at 10:32 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
>> > It should not be too hard. IO schedulers already create
>> > /sys/block/<dev>/queue/iosched/ dir and we can create <dev>/queue/throttle/
>> > dir and export throttle related tunables there.
>>
>> Evening, Vivek.
>>
>> I worked the framework for the tunable out.
>>
>> If in right direction, I will complete it soon.
>
> Hillf,
>
> You still have not answered my questions in previous mail.

Thank you, Vivek, for patience first.

>
> - What's the problem are you facing and how filling the quantum to the
> Âcapacity is helping you.

The community in which we live holds multiple elements, you see, and
it is not rare that readers could have different sights from the
writer of the artwork concerned. As the quantum defined, dispatching
should be as natural and smoothly as definition permits. And it
happened that the same concern is raised by other readers.

There are only two chances left in block throttle, a new concept in
block dir, for its readers. I was moved by the art of rb_tree at first
peek, and even tried to find the mm leakage of throttle group but
failed :-0)

>
> - Tunable and filling the quantum are two different things. If filling
> Âthe quantum solved your problem, then how tunable is going to solve
> Âsame problem.

Tunable looks necessary here since the maintainer of block offers
sysfs methods to tune his elevators, even in case of the CFQ. That is
the cool way to solve problems, I think.

>
> I don't want to introduce tunables if they are really not put to use
> by somebody. So before we move in this direction, lets first answer
> above questions.

The naive framework for the tunable is prepared for playing my games,
and shared if others concern, not ready for block throttle yet
currently, but it should be in right direction first. And it is honor
to ask for confirm from the author, right?

Cheers
Hillf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/