linux-kernel - Re: [patch 11/12][CFQ-cgroup] Control service tree: Main functions

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>] [day] [month] [year] [list]

Date:	Mon, 16 Jun 2008 16:11:28 -0700
From:	Divyesh Shah <dpshah@...gle.com>
To:	Satoshi UCHIDA <s-uchida@...jp.nec.com>
Cc:	linux-kernel@...r.kernel.org, ryov@...inux.co.jp, axboe@...nel.dk,
	vtaras@...nvz.org, containers@...ts.linux-foundation.org
Subject: Re: [patch 11/12][CFQ-cgroup] Control service tree: Main functions

> From: "Satoshi UCHIDA" <s-uch...@...jp.nec.com>
> Date: Apr 3, 12:20 am
> Subject: [patch 11/12][CFQ-cgroup] Control service tree: Main
> functions
>
> This patch introduced to control cfq_data.
> Its algorithm is similar to one when CFQ synchronous I/O.
>
> The new cfq optional operations:
> The "cfq_dispatch_requests_fn" defines a function which is implemented
> request dispatching algorithm.
> This becomes main function for fairness.
>
> The "cfq_completed_request_after_fn" defines a function which winds up
> I/O's
> affairs.
>
> The "cfq_active_check_fn" defines a function which make sure whether
> selecting cfq_data is equal to active cfq_data.
>
> The "cfq_empty_fn" defines a function which check whether active data
> exists.
>
>       Signed-off-by:SatoshiUCHIDA<uch...@...jp.nec.com>
>

Hi Satoshi,
      I was wondering if adding queue preemption to your design might  
be useful.

If I understand correctly, currently if a higher priority cgroup is  
only able to use
up a part of its time-slice (due to few requests) in a given round- 
robin iteration,
it will need to wait for some other cgroups to get a shot at the disk  
before it can get
its chance in the next iteration (though the residual timeslice helps  
it get resorted to
a better position in the rr).

IMO, this high priority cgroup should have been able to get in and  
send a few more requests
to disk till it uses up its remaining timeslice by preempting the  
current lower priority cgroup.

This same argument can also be presented against CFQ but is more  
valid here when we are working with
cgroups instead of individual processes as in production environments  
collection of tasks which are
marked high-priority would often expect/require that level of  
service. Also, something like this
could be implemented as a knob so that it can be turned on/off  
depending on the use-case.

Does this make sense?

-Divyesh
--
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/