linux-kernel - Re: [PATCH] maximize dispatching in block throttle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 7 Dec 2010 21:22:31 +0800
From:	Hillf Danton <dhillf@...il.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] maximize dispatching in block throttle

On Mon, Dec 6, 2010 at 10:54 PM, Vivek Goyal <vgoyal@...hat.com> 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@...hat.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/