Andrea Righi wrote:
A more complicated issue is how to evaluate the total IO bandwidth of a
generic device. We can use some kind of averaging/prediction, but
basically it would be inaccurate due to the mechanic of disks (head
seeks, but also caching, buffering mechanisms implemented directly
Hi,
2008/8/13 Andrea Righi [EMAIL PROTECTED]:
Fernando Luis Vázquez Cao wrote:
On Tue, 2008-08-12 at 22:29 +0900, Andrea Righi wrote:
Andrea Righi wrote:
Hirokazu Takahashi wrote:
3. 4. 5. - I/O bandwidth shaping General design aspects
The implementation of an I/O scheduling algorithm
Dong-Jae Kang wrote:
Hi,
2008/8/13 Andrea Righi [EMAIL PROTECTED]:
Fernando Luis Vázquez Cao wrote:
On Tue, 2008-08-12 at 22:29 +0900, Andrea Righi wrote:
Andrea Righi wrote:
Hirokazu Takahashi wrote:
3. 4. 5. - I/O bandwidth shaping General design aspects
The implementation of an
Hi,
Fernando Luis Vázquez Cao wrote:
This seems to be the easiest part, but the current cgroups
infrastructure has some limitations when it comes to dealing with block
devices: impossibility of creating/removing certain control structures
dynamically and hardcoding of subsystems
Hirokazu Takahashi wrote:
3. 4. 5. - I/O bandwidth shaping General design aspects
The implementation of an I/O scheduling algorithm is to a certain extent
influenced by what we are trying to achieve in terms of I/O bandwidth
shaping, but, as discussed below, the required accuracy can
On Tue, 2008-08-12 at 20:52 +0900, Hirokazu Takahashi wrote:
Hi,
Fernando Luis Vázquez Cao wrote:
This seems to be the easiest part, but the current cgroups
infrastructure has some limitations when it comes to dealing with
block
devices: impossibility of creating/removing
On Tue, 2008-08-12 at 22:29 +0900, Andrea Righi wrote:
Andrea Righi wrote:
Hirokazu Takahashi wrote:
3. 4. 5. - I/O bandwidth shaping General design aspects
The implementation of an I/O scheduling algorithm is to a certain
extent
influenced by what we are trying to achieve in
Fernando Luis Vázquez Cao wrote:
On Tue, 2008-08-12 at 22:29 +0900, Andrea Righi wrote:
Andrea Righi wrote:
Hirokazu Takahashi wrote:
3. 4. 5. - I/O bandwidth shaping General design aspects
The implementation of an I/O scheduling algorithm is to a certain
extent
influenced by what we
[EMAIL PROTECTED] wrote:
Fernando Luis Vázquez Cao wrote:
BTW as I said in a previous email, an interesting path to
be explored
IMHO could be to think in terms of IO time. So, look at the
time an IO
request is issued to the drive, look at the time the
request is served,
evaluate the
Fernando Luis Vázquez Cao wrote:
BTW as I said in a previous email, an interesting path to
be explored
IMHO could be to think in terms of IO time. So, look at the
time an IO
request is issued to the drive, look at the time the
request is served,
evaluate the difference and charge the
A minor sidebar:
2008/8/7 Fernando Luis Vázquez Cao [EMAIL PROTECTED] wrote
On the one hand, we have the problem of feeding physical devices with IO
requests in such a way that we squeeze the maximum performance out of
them. Of course in some cases we may want to prioritize responsiveness
over
Hello Fernando
2008/8/7 Fernando Luis Vázquez Cao [EMAIL PROTECTED]:
Hi Naveen,
On Wed, 2008-08-06 at 12:37 -0700, Naveen Gupta wrote:
3. 4. 5. - I/O bandwidth shaping General design aspects
The implementation of an I/O scheduling algorithm is to a certain extent
influenced by what
Andrea Righi [EMAIL PROTECTED] writes:
Fernando Luis Vázquez Cao wrote:
This seems to be the easiest part, but the current cgroups
infrastructure has some limitations when it comes to dealing with block
devices: impossibility of creating/removing certain control structures
dynamically
Fernando Luis Vázquez Cao wrote:
This seems to be the easiest part, but the current cgroups
infrastructure has some limitations when it comes to dealing with block
devices: impossibility of creating/removing certain control structures
dynamically and hardcoding of subsystems (i.e. resource
On Fri, 2008-08-08 at 20:39 +0900, Hirokazu Takahashi wrote:
Hi,
Would you like to split up IO into read and write IO. We know that read
can be
very latency sensitive when compared to writes. Should we consider them
separately in the RFC?
Oops, I somehow ended up leaving your
Hi, Fernando,
It's a good work!
*** How to move on
As discussed before, it probably makes sense to have both a block layer
I/O controller and a elevator-based one, and they could certainly
cohabitate. As discussed before, all of them need I/O tracking
capabilities so I would like to
Hi,
- Implement a block layer resource controller. dm-ioband is a working
solution and feature rich but its dependency on the dm infrastructure is
likely to find opposition (the dm layer does not handle barriers
properly and the maximum size of I/O requests can be limited in some
Hi Fernando,
- Implement a block layer resource controller. dm-ioband is a working
solution and feature rich but its dependency on the dm infrastructure is
likely to find opposition (the dm layer does not handle barriers
properly and the maximum size of I/O requests can be
Hi,
Would you like to split up IO into read and write IO. We know that read can
be
very latency sensitive when compared to writes. Should we consider them
separately in the RFC?
Oops, I somehow ended up leaving your first question unanswered. Sorry.
I do not think we should consider
Hi, Fernando,
- Implement a block layer resource controller. dm-ioband is a working
solution and feature rich but its dependency on the dm infrastructure is
likely to find opposition (the dm layer does not handle barriers
properly and the maximum size of I/O requests can be limited in
Fernando Luis Vázquez Cao wrote:
This RFC ended up being a bit longer than I had originally intended, but
hopefully it will serve as the start of a fruitful discussion.
Thanks for posting this detailed RFC! A few comments below.
As you pointed out, it seems that there is not much consensus
Hi, Naveen,
If we are pursuing a I/O prioritization model à la CFQ the temptation is
to implement it at the elevator layer or extend any of the existing I/O
schedulers.
There have been several proposals that extend either the CFQ scheduler
(see (1), (2) below) or the AS scheduler (see
Hi Naveen,
On Wed, 2008-08-06 at 12:37 -0700, Naveen Gupta wrote:
3. 4. 5. - I/O bandwidth shaping General design aspects
The implementation of an I/O scheduling algorithm is to a certain extent
influenced by what we are trying to achieve in terms of I/O bandwidth
shaping, but, as
Hi Andrea!
On Thu, 2008-08-07 at 09:46 +0200, Andrea Righi wrote:
Fernando Luis Vázquez Cao wrote:
This RFC ended up being a bit longer than I had originally intended, but
hopefully it will serve as the start of a fruitful discussion.
Thanks for posting this detailed RFC! A few comments
Hi Fernando,
This RFC ended up being a bit longer than I had originally intended, but
hopefully it will serve as the start of a fruitful discussion.
Thanks a lot for posting the RFC.
*** Goals
1. Cgroups-aware I/O scheduling (being able to define arbitrary
groupings of processes and
On Wed, 2008-08-06 at 15:18 +0900, Ryo Tsuruta wrote:
Hi Fernando,
This RFC ended up being a bit longer than I had originally intended, but
hopefully it will serve as the start of a fruitful discussion.
Thanks a lot for posting the RFC.
*** Goals
1. Cgroups-aware I/O scheduling
On Wed, 2008-08-06 at 15:41 +0900, Fernando Luis Vázquez Cao wrote:
I agree with your plan.
We keep bio-cgroup improving and porting to the latest kernel.
Having more users of bio-cgroup would probably help to get it merged, so
we'll certainly send patches as soon as we get our cfq prototype
Fernando Luis Vázquez Cao wrote:
On Mon, 2008-08-04 at 10:20 -0700, Dave Hansen wrote:
On Mon, 2008-08-04 at 17:51 +0900, Ryo Tsuruta wrote:
This series of patches of dm-ioband now includes The bio tracking
mechanism,
which has been posted individually to this mailing list.
This makes it
On Wed, 2008-08-06 at 22:12 +0530, Balbir Singh wrote:
1. 2.- Cgroups-aware I/O scheduling (being able to define arbitrary
groupings of processes and treat each group as a single scheduling
identity)
We obviously need this because our final goal is to be able to control
the IO
On Wed, 2008-08-06 at 22:12 +0530, Balbir Singh wrote:
*** Goals
1. Cgroups-aware I/O scheduling (being able to define arbitrary
groupings of processes and treat each group as a single scheduling
entity).
2. Being able to perform I/O bandwidth control independently on each
device.
On Wed, 2008-08-06 at 08:48 -0700, Dave Hansen wrote:
On Wed, 2008-08-06 at 15:41 +0900, Fernando Luis Vázquez Cao wrote:
I agree with your plan.
We keep bio-cgroup improving and porting to the latest kernel.
Having more users of bio-cgroup would probably help to get it merged, so
we'll
31 matches
Mail list logo
