This is a discussion on Re: [patch 11/12][CFQ-cgroup] Control service tree: Main functions - Kernel ; > From: "Satoshi UCHIDA" > 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. > ...
> From: "Satoshi UCHIDA"
> Date: Apr 3, 12:20 am
> Subject: [patch 11/12][CFQ-cgroup] Control service tree: Main
> 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
> 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
I was wondering if adding queue preemption to your design might
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-
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?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/