Re: RFC: I/O bandwidth controller
- From: Andrea Righi <righi.andrea@xxxxxxxxx>
- Date: Tue, 12 Aug 2008 23:00:30 +0200
James.Smart@xxxxxxxxxx wrote:
Fernando Luis Vázquez Cao wrote:
BTW as I said in a previous email, an interesting path tobe explored
IMHO could be to think in terms of IO time. So, look at thetime an IO
request is issued to the drive, look at the time therequest is served,
evaluate the difference and charge the consumed IO time to thePlease note that the seek time for a specific IO request is strongly
appropriate cgroup. Then dispatch IO requests in function of the
consumed IO time debts / credits, using for example a token-bucket
strategy. And probably the best place to implement the IO time
accounting is the elevator.
correlated with the IO requests that preceded it, which means that the
owner of that request is not the only one to blame if it
takes too long
to process it. In other words, with the algorithm you propose
we may end
up charging the wrong guy.
I assume all of these discussions are focused on simple storage - disks
direct attached to a single server - and are not targeted at SANs with
arrays, multi-initiator accesses, and fabric/network impacts. True ?
Such algorithms can be seriously off-base in these latter configurations.
Accounting the IO cost using time values should be in principle a
topology-agnostic solution, so it should work both for LUs from SAN,
magnetic disks, USB drive, optical drives, etc. because we're actually
looking at the time spent to execute each IO operation (and you don't
need to know the details of the particular IO operation, because you
automatically know the actual cost).
If you mean that trying to evaluate or even predict the cost of the seek
ops is so meaningful in those "complex" environments, well.. yes, in
this case I agree.
-Andrea
--
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/
- References:
- Re: RFC: I/O bandwidth controller (was Re: Too many I/O controller patches)
- From: Fernando Luis Vázquez Cao
- Re: RFC: I/O bandwidth controller (was Re: Too many I/O controller patches)
- From: Andrea Righi
- Re: RFC: I/O bandwidth controller
- From: Hirokazu Takahashi
- Re: RFC: I/O bandwidth controller
- From: Andrea Righi
- Re: RFC: I/O bandwidth controller
- From: Andrea Righi
- Re: RFC: I/O bandwidth controller
- From: Fernando Luis Vázquez Cao
- RE: RFC: I/O bandwidth controller
- From: James . Smart
- Re: RFC: I/O bandwidth controller (was Re: Too many I/O controller patches)
- Prev by Date: Re: [RFC] readdir mess
- Next by Date: Re: [PATCH] Intel Management Engine Interface
- Previous by thread: RE: RFC: I/O bandwidth controller
- Next by thread: Re: RFC: I/O bandwidth controller
- Index(es):
Relevant Pages
|