Not to compound upon this again. However if BFQ isn't suitable to
replace CFQ for high I/O workloads (I've yet to see 20k IOPS on any
reasonably sized SAN (SC4020 / v5000, etc)), can't we at-least default
BFQ to become the default I/O scheduler for people otherwise
requesting CFQ? Paolo has had a t
> Il giorno 14 ott 2016, alle ore 20:35, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Fri, Oct 14, 2016 at 07:13:41PM +0200, Paolo Valente wrote:
>> That said, your 'thus' seems a little too strong: "bfq does not yet
>> handle fast SSDs, thus we need something else". What about the
>> millio
Hello, Paolo.
On Fri, Oct 14, 2016 at 07:13:41PM +0200, Paolo Valente wrote:
> That said, your 'thus' seems a little too strong: "bfq does not yet
> handle fast SSDs, thus we need something else". What about the
> millions of devices (and people) still within 10-20 K IOPS, and
> experiencing awfu
> Il giorno 14 ott 2016, alle ore 18:40, Tejun Heo ha scritto:
>
> Hello, Kyle.
>
> On Sat, Oct 08, 2016 at 06:15:14PM -0700, Kyle Sanderson wrote:
>> How is this even a discussion when hard numbers, and trying any
>> reproduction case easily reproduce the issues that CFQ causes. Reading
>> thi
Hello, Kyle.
On Sat, Oct 08, 2016 at 06:15:14PM -0700, Kyle Sanderson wrote:
> How is this even a discussion when hard numbers, and trying any
> reproduction case easily reproduce the issues that CFQ causes. Reading
> this thread, and many others only grows not only my disappointment,
> but whenev
Re-sending as plain-text as the Gmail Android App is still
historically broken...
-- Forwarded message --
From: Kyle Sanderson
Date: Wed, Oct 5, 2016 at 7:09 AM
Subject: Re: [PATCH V3 00/11] block-throttle: add .high limit
To: Tejun Heo
Cc: jmo...@redhat.com, Paolo Valente
On 06.10.2016, Linus Walleij wrote:
> Not just desktops, also Android phones.
> So why not have BFQ as a separate scheduling policy upstream,
> alongside CFQ, deadline and noop?
Please, just do it! CFQ and deadline perform horribly on Android, and
the same is true for desktop systems based on
> Il giorno 06 ott 2016, alle ore 21:57, Shaohua Li ha scritto:
>
> On Thu, Oct 06, 2016 at 09:58:44AM +0200, Paolo Valente wrote:
>>
>>> Il giorno 05 ott 2016, alle ore 22:46, Shaohua Li ha scritto:
>>>
>>> On Wed, Oct 05, 2016 at 09:47:19PM +0200, Paolo Valente wrote:
> Il giorno
> Il giorno 06 ott 2016, alle ore 20:32, Vivek Goyal ha
> scritto:
>
> On Thu, Oct 06, 2016 at 08:01:42PM +0200, Paolo Valente wrote:
>>
>>> Il giorno 06 ott 2016, alle ore 19:49, Vivek Goyal ha
>>> scritto:
>>>
>>> On Thu, Oct 06, 2016 at 03:15:50PM +0200, Paolo Valente wrote:
>>>
>>> [..
On Thu, Oct 06, 2016 at 09:58:44AM +0200, Paolo Valente wrote:
>
> > Il giorno 05 ott 2016, alle ore 22:46, Shaohua Li ha scritto:
> >
> > On Wed, Oct 05, 2016 at 09:47:19PM +0200, Paolo Valente wrote:
> >>
> >>> Il giorno 05 ott 2016, alle ore 20:30, Shaohua Li ha
> >>> scritto:
> >>>
> >>>
On Thu, Oct 06, 2016 at 01:49:43PM -0400, Vivek Goyal wrote:
> Paolo, CFQ is legacy now and if we can come up with a proportional
> IO mechanism which works reasonably well with fast devices using
> blk-mq interfaces, that will be much more interesting.
CFQ is not legacy yet. Until we've got sch
On Thu, Oct 06, 2016 at 08:01:42PM +0200, Paolo Valente wrote:
>
> > Il giorno 06 ott 2016, alle ore 19:49, Vivek Goyal ha
> > scritto:
> >
> > On Thu, Oct 06, 2016 at 03:15:50PM +0200, Paolo Valente wrote:
> >
> > [..]
> >> Shaohua, I have just realized that I have unconsciously defended a
>
> Il giorno 06 ott 2016, alle ore 19:49, Vivek Goyal ha
> scritto:
>
> On Thu, Oct 06, 2016 at 03:15:50PM +0200, Paolo Valente wrote:
>
> [..]
>> Shaohua, I have just realized that I have unconsciously defended a
>> wrong argument. Although all the facts that I have reported are
>> evidently
On Thu, Oct 06, 2016 at 03:15:50PM +0200, Paolo Valente wrote:
[..]
> Shaohua, I have just realized that I have unconsciously defended a
> wrong argument. Although all the facts that I have reported are
> evidently true, I have argued as if the question was: "do we need to
> throw away throttling
On 2016-10-06 11:05, Paolo Valente wrote:
Il giorno 06 ott 2016, alle ore 15:52, Austin S. Hemmelgarn
ha scritto:
On 2016-10-06 08:50, Paolo Valente wrote:
Il giorno 06 ott 2016, alle ore 13:57, Austin S. Hemmelgarn
ha scritto:
On 2016-10-06 07:03, Mark Brown wrote:
On Thu, Oct 06, 20
> Il giorno 06 ott 2016, alle ore 15:52, Austin S. Hemmelgarn
> ha scritto:
>
> On 2016-10-06 08:50, Paolo Valente wrote:
>>
>>> Il giorno 06 ott 2016, alle ore 13:57, Austin S. Hemmelgarn
>>> ha scritto:
>>>
>>> On 2016-10-06 07:03, Mark Brown wrote:
On Thu, Oct 06, 2016 at 10:04:41AM
On 2016-10-06 08:50, Paolo Valente wrote:
Il giorno 06 ott 2016, alle ore 13:57, Austin S. Hemmelgarn
ha scritto:
On 2016-10-06 07:03, Mark Brown wrote:
On Thu, Oct 06, 2016 at 10:04:41AM +0200, Linus Walleij wrote:
On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo wrote:
I get that bfq can be
> Il giorno 06 ott 2016, alle ore 09:58, Paolo Valente
> ha scritto:
>
>>
>> Il giorno 05 ott 2016, alle ore 22:46, Shaohua Li ha scritto:
>>
>> On Wed, Oct 05, 2016 at 09:47:19PM +0200, Paolo Valente wrote:
>>>
Il giorno 05 ott 2016, alle ore 20:30, Shaohua Li ha scritto:
> Il giorno 06 ott 2016, alle ore 13:57, Austin S. Hemmelgarn
> ha scritto:
>
> On 2016-10-06 07:03, Mark Brown wrote:
>> On Thu, Oct 06, 2016 at 10:04:41AM +0200, Linus Walleij wrote:
>>> On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo wrote:
>>
I get that bfq can be a good compromise on most
On 2016-10-06 07:03, Mark Brown wrote:
On Thu, Oct 06, 2016 at 10:04:41AM +0200, Linus Walleij wrote:
On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo wrote:
I get that bfq can be a good compromise on most desktop workloads and
behave reasonably well for some server workloads with the slice
expirat
On Thu, Oct 06, 2016 at 10:04:41AM +0200, Linus Walleij wrote:
> On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo wrote:
> > 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 is
On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo wrote:
> 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.
Not just desktops, also A
> Il giorno 05 ott 2016, alle ore 22:46, Shaohua Li ha scritto:
>
> On Wed, Oct 05, 2016 at 09:47:19PM +0200, Paolo Valente wrote:
>>
>>> Il giorno 05 ott 2016, alle ore 20:30, Shaohua Li ha scritto:
>>>
>>> On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote:
Hello, Paolo.
>
> Il giorno 05 ott 2016, alle ore 22:36, Shaohua Li ha scritto:
>
> On Wed, Oct 05, 2016 at 09:57:22PM +0200, Paolo Valente wrote:
>>
>>> Il giorno 05 ott 2016, alle ore 21:08, Shaohua Li ha scritto:
>>>
>>> On Wed, Oct 05, 2016 at 11:30:53AM -0700, Shaohua Li wrote:
On Wed, Oct 05, 2016
On Wed, Oct 05, 2016 at 09:47:19PM +0200, Paolo Valente wrote:
>
> > Il giorno 05 ott 2016, alle ore 20:30, Shaohua Li ha scritto:
> >
> > On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote:
> >> Hello, Paolo.
> >>
> >> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote:
> >>>
On Wed, Oct 05, 2016 at 09:57:22PM +0200, Paolo Valente wrote:
>
> > Il giorno 05 ott 2016, alle ore 21:08, Shaohua Li ha scritto:
> >
> > On Wed, Oct 05, 2016 at 11:30:53AM -0700, Shaohua Li wrote:
> >> On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote:
> >>> Hello, Paolo.
> >>>
> >>>
> Il giorno 05 ott 2016, alle ore 21:47, Paolo Valente
> ha scritto:
>
>>
>> Il giorno 05 ott 2016, alle ore 20:30, Shaohua Li ha scritto:
>>
>> On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote:
>>> Hello, Paolo.
>>>
>>> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote
> Il giorno 05 ott 2016, alle ore 21:08, Shaohua Li ha scritto:
>
> On Wed, Oct 05, 2016 at 11:30:53AM -0700, Shaohua Li wrote:
>> On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote:
>>> Hello, Paolo.
>>>
>>> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote:
In this res
> Il giorno 05 ott 2016, alle ore 20:30, Shaohua Li ha scritto:
>
> On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote:
>> Hello, Paolo.
>>
>> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote:
>>> In this respect, for your generic, unpredictable scenario to make
>>> sense, t
On Wed, Oct 05, 2016 at 11:30:53AM -0700, Shaohua Li wrote:
> On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote:
> > Hello, Paolo.
> >
> > On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote:
> > > In this respect, for your generic, unpredictable scenario to make
> > > sense, the
On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote:
> Hello, Paolo.
>
> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote:
> > In this respect, for your generic, unpredictable scenario to make
> > sense, there must exist at least one real system that meets the
> > requirements o
Hello, Paolo.
On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote:
> In this respect, for your generic, unpredictable scenario to make
> sense, there must exist at least one real system that meets the
> requirements of such a scenario. Or, if such a real system does not
> yet exist, it
> Il giorno 05 ott 2016, alle ore 15:12, Vivek Goyal ha
> scritto:
>
> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote:
>
> [..]
>> Anyway, to avoid going on with trying speculations and arguments, let
>> me retry with a practical proposal. BFQ is out there, free. Let's
>> just
On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote:
[..]
> Anyway, to avoid going on with trying speculations and arguments, let
> me retry with a practical proposal. BFQ is out there, free. Let's
> just test, measure and check whether we have already a solution to
> the problems you/
> Il giorno 04 ott 2016, alle ore 22:27, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Tue, Oct 04, 2016 at 09:29:48PM +0200, Paolo Valente wrote:
>>> 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
>>>
Hello, Paolo.
On Tue, Oct 04, 2016 at 09:29:48PM +0200, Paolo Valente wrote:
> > 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
> > und
> Il giorno 04 ott 2016, alle ore 20:28, Shaohua Li ha scritto:
>
> On Tue, Oct 04, 2016 at 07:43:48PM +0200, Paolo Valente wrote:
>>
>>> Il giorno 04 ott 2016, alle ore 19:28, Shaohua Li ha scritto:
>>>
>>> On Tue, Oct 04, 2016 at 07:01:39PM +0200, Paolo Valente wrote:
> Il giorno
> Il giorno 04 ott 2016, alle ore 21:14, Tejun Heo ha scritto:
>
> 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 wi
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, num
> Il giorno 04 ott 2016, alle ore 20:54, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Tue, Oct 04, 2016 at 07:43:48PM +0200, Paolo Valente wrote:
>>> I don't think IO bandwidth does not matter. The problem is bandwidth can't
>>> measure IO cost. For example, you can't say 8k IO costs 2x IO re
> Il giorno 04 ott 2016, alle ore 20:50, Tejun Heo ha scritto:
>
> Hello, Vivek.
>
> On Tue, Oct 04, 2016 at 02:12:45PM -0400, Vivek Goyal wrote:
>> Agreed that we don't have a good basic unit to measure IO cost. I was
>> thinking of measuring cost in terms of sectors as that's simple and
>> ge
Hello, Paolo.
On Tue, Oct 04, 2016 at 07:43:48PM +0200, Paolo Valente wrote:
> > I don't think IO bandwidth does not matter. The problem is bandwidth can't
> > measure IO cost. For example, you can't say 8k IO costs 2x IO resource than
> > 4k
> > IO.
>
> For what goal do you need to be able to s
Hello, Vivek.
On Tue, Oct 04, 2016 at 02:12:45PM -0400, Vivek Goyal wrote:
> Agreed that we don't have a good basic unit to measure IO cost. I was
> thinking of measuring cost in terms of sectors as that's simple and
> gets more accurate on faster devices with almost no seek penalty. And
If this
On Tue, Oct 04, 2016 at 07:43:48PM +0200, Paolo Valente wrote:
>
> > Il giorno 04 ott 2016, alle ore 19:28, Shaohua Li ha scritto:
> >
> > On Tue, Oct 04, 2016 at 07:01:39PM +0200, Paolo Valente wrote:
> >>
> >>> Il giorno 04 ott 2016, alle ore 18:27, Tejun Heo ha
> >>> scritto:
> >>>
> >>>
On Tue, Oct 04, 2016 at 11:56:16AM -0400, Tejun Heo wrote:
> Hello, Vivek.
>
> On Tue, Oct 04, 2016 at 09:28:05AM -0400, Vivek Goyal wrote:
> > On Mon, Oct 03, 2016 at 02:20:19PM -0700, Shaohua Li wrote:
> > > Hi,
> > >
> > > The background is we don't have an ioscheduler for blk-mq yet, so we ca
> Il giorno 04 ott 2016, alle ore 19:28, Shaohua Li ha scritto:
>
> On Tue, Oct 04, 2016 at 07:01:39PM +0200, Paolo Valente wrote:
>>
>>> Il giorno 04 ott 2016, alle ore 18:27, Tejun Heo ha
>>> scritto:
>>>
>>> Hello,
>>>
>>> On Tue, Oct 04, 2016 at 06:22:28PM +0200, Paolo Valente wrote:
>>
On Tue, Oct 04, 2016 at 07:01:39PM +0200, Paolo Valente wrote:
>
> > Il giorno 04 ott 2016, alle ore 18:27, Tejun Heo ha
> > scritto:
> >
> > Hello,
> >
> > On Tue, Oct 04, 2016 at 06:22:28PM +0200, Paolo Valente wrote:
> >> Could you please elaborate more on this point? BFQ uses sectors
> >>
Hi,
On Tue, Oct 04, 2016 at 09:28:05AM -0400, Vivek Goyal wrote:
> On Mon, Oct 03, 2016 at 02:20:19PM -0700, Shaohua Li wrote:
> > Hi,
> >
> > The background is we don't have an ioscheduler for blk-mq yet, so we can't
> > prioritize processes/cgroups.
>
> So this is an interim solution till we ha
> Il giorno 04 ott 2016, alle ore 18:27, Tejun Heo ha scritto:
>
> Hello,
>
> On Tue, Oct 04, 2016 at 06:22:28PM +0200, Paolo Valente wrote:
>> Could you please elaborate more on this point? BFQ uses sectors
>> served to measure service, and, on the all the fast devices on which
>> we have tes
Hello,
On Tue, Oct 04, 2016 at 06:22:28PM +0200, Paolo Valente wrote:
> Could you please elaborate more on this point? BFQ uses sectors
> served to measure service, and, on the all the fast devices on which
> we have tested it, it accurately distributes
> bandwidth as desired, redistributes exces
> Il giorno 04 ott 2016, alle ore 17:56, Tejun Heo ha scritto:
>
> Hello, Vivek.
>
> On Tue, Oct 04, 2016 at 09:28:05AM -0400, Vivek Goyal wrote:
>> On Mon, Oct 03, 2016 at 02:20:19PM -0700, Shaohua Li wrote:
>>> Hi,
>>>
>>> The background is we don't have an ioscheduler for blk-mq yet, so we
Hello, Vivek.
On Tue, Oct 04, 2016 at 09:28:05AM -0400, Vivek Goyal wrote:
> On Mon, Oct 03, 2016 at 02:20:19PM -0700, Shaohua Li wrote:
> > Hi,
> >
> > The background is we don't have an ioscheduler for blk-mq yet, so we can't
> > prioritize processes/cgroups.
>
> So this is an interim solution
On Mon, Oct 03, 2016 at 02:20:19PM -0700, Shaohua Li wrote:
> Hi,
>
> The background is we don't have an ioscheduler for blk-mq yet, so we can't
> prioritize processes/cgroups.
So this is an interim solution till we have ioscheduler for blk-mq?
> This patch set tries to add basic arbitration
> b
Hi,
The background is we don't have an ioscheduler for blk-mq yet, so we can't
prioritize processes/cgroups. This patch set tries to add basic arbitration
between cgroups with blk-throttle. It adds a new limit io.high for
blk-throttle. It's only for cgroup2.
io.max is a hard limit throttling. cgr
54 matches
Mail list logo
