[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090312001146.74591b9d.akpm@linux-foundation.org>
Date: Thu, 12 Mar 2009 00:11:46 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: nauman@...gle.com, dpshah@...gle.com, lizf@...fujitsu.com,
mikew@...gle.com, fchecconi@...il.com, paolo.valente@...more.it,
jens.axboe@...cle.com, ryov@...inux.co.jp,
fernando@...ellilink.co.jp, s-uchida@...jp.nec.com,
taka@...inux.co.jp, guijianfeng@...fujitsu.com,
arozansk@...hat.com, jmoyer@...hat.com, oz-kernel@...hat.com,
dhaval@...ux.vnet.ibm.com, balbir@...ux.vnet.ibm.com,
linux-kernel@...r.kernel.org,
containers@...ts.linux-foundation.org, menage@...gle.com,
peterz@...radead.org
Subject: Re: [PATCH 01/10] Documentation
On Wed, 11 Mar 2009 21:56:46 -0400 Vivek Goyal <vgoyal@...hat.com> wrote:
> +Currently "current" task
> +is used to determine the cgroup (hence io group) of the request. Down the
> +line we need to make use of bio-cgroup patches to map delayed writes to
> +right group.
You handled this problem pretty neatly!
It's always been a BIG problem for all the io-controlling schemes, and
most of them seem to have "handled" it in the above way :(
But for many workloads, writeback is the majority of the IO and it has
always been the form of IO which has caused us the worst contention and
latency problems. So I don't think that we can proceed with _anything_
until we at least have a convincing plan here.
Also.. there are so many IO controller implementations that I've lost
track of who is doing what. I do have one private report here that
Andreas's controller "is incredibly productive for us and has allowed
us to put twice as many users per server with faster times for all
users". Which is pretty stunning, although it should be viewed as a
condemnation of the current code, I'm afraid.
So my question is: what is the definitive list of
proposed-io-controller-implementations and how do I cunningly get all
you guys to check each others homework? :)
--
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