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
| ||
|
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/
Powered by blists - more mailing lists