[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161004191427.GG4205@htj.duckdns.org>
Date: Tue, 4 Oct 2016 15:14:27 -0400
From: Tejun Heo <tj@...nel.org>
To: Paolo Valente <paolo.valente@...more.it>
Cc: Shaohua Li <shli@...com>, Vivek Goyal <vgoyal@...hat.com>,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
Jens Axboe <axboe@...com>, Kernel-team@...com,
jmoyer@...hat.com, Mark Brown <broonie@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH V3 00/11] block-throttle: add .high limit
Hello, Paolo.
On Tue, Oct 04, 2016 at 09:02:47PM +0200, Paolo Valente wrote:
> That's exactly what BFQ has succeeded in doing in all the tests
> devised so far. Can you give me a concrete example for which I can
> try with BFQ and with any other mechanism you deem better. If
> you are right, numbers will just make your point.
Hmm... I think we already discussed this but here's a really simple
case. There are three unknown workloads A, B and C and we want to
give A certain best-effort guarantees (let's say around 80% of the
underlying device) whether A is sharing the device with B or C.
I get that bfq can be a good compromise on most desktop workloads and
behave reasonably well for some server workloads with the slice
expiration mechanism but it really isn't an IO resource partitioning
mechanism.
Thanks.
--
tejun
Powered by blists - more mailing lists