Hoping that it may help people get a better idea of the features of bfq (while
we work on the patches), I just uploaded a new, shorter demo (7 minutes) of BFQ
with an SSD:
http://youtu.be/KhZl9LjCKuU
Paolo
Il giorno 23/giu/2014, alle ore 21:20, Tejun Heo ha scritto:
> On Mon, Jun 23, 2014 at
Hoping that it may help people get a better idea of the features of bfq (while
we work on the patches), I just uploaded a new, shorter demo (7 minutes) of BFQ
with an SSD:
http://youtu.be/KhZl9LjCKuU
Paolo
Il giorno 23/giu/2014, alle ore 21:20, Tejun Heo t...@kernel.org ha scritto:
On Mon,
On Mon, Jun 23, 2014 at 03:53:09PM +0200, Paolo Valente wrote:
> I will wait shortly for a possible feedback on this proposal, and,
> then, if nothing has still to be changed or refined, silently start
> the process.
We'll prolly end up doing a few iterations but overall it sounds good
to me.
Il giorno 19/giu/2014, alle ore 04:29, Jens Axboe ha scritto:
> On 2014-06-18 18:46, Tejun Heo wrote:
>> Hello,
>>
>> On Tue, Jun 17, 2014 at 05:55:57PM +0200, Paolo Valente wrote:
>>> In general, with both a smooth but messy and a sharp but clean
>>> transformation, there seems to be the
Il giorno 19/giu/2014, alle ore 04:29, Jens Axboe ax...@kernel.dk ha scritto:
On 2014-06-18 18:46, Tejun Heo wrote:
Hello,
On Tue, Jun 17, 2014 at 05:55:57PM +0200, Paolo Valente wrote:
In general, with both a smooth but messy and a sharp but clean
transformation, there seems to be the
On Mon, Jun 23, 2014 at 03:53:09PM +0200, Paolo Valente wrote:
I will wait shortly for a possible feedback on this proposal, and,
then, if nothing has still to be changed or refined, silently start
the process.
We'll prolly end up doing a few iterations but overall it sounds good
to me.
On 2014-06-18 18:46, Tejun Heo wrote:
Hello,
On Tue, Jun 17, 2014 at 05:55:57PM +0200, Paolo Valente wrote:
In general, with both a smooth but messy and a sharp but clean
transformation, there seems to be the following common problems:
1) The main benefits highlighted by Jens, i.e., being
On Wed, Jun 18, 2014 at 09:46:00PM -0400, Tejun Heo wrote:
...
> So, the perfectly smooth and performant transformation is possible,
^
if
> it'd be great, but I don't really think that'd be the case. My
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe
Hello,
On Tue, Jun 17, 2014 at 05:55:57PM +0200, Paolo Valente wrote:
> In general, with both a smooth but messy and a sharp but clean
> transformation, there seems to be the following common problems:
>
> 1) The main benefits highlighted by Jens, i.e., being able to move
> back and forth and
Hello,
On Tue, Jun 17, 2014 at 05:55:57PM +0200, Paolo Valente wrote:
In general, with both a smooth but messy and a sharp but clean
transformation, there seems to be the following common problems:
1) The main benefits highlighted by Jens, i.e., being able to move
back and forth and easily
On Wed, Jun 18, 2014 at 09:46:00PM -0400, Tejun Heo wrote:
...
So, the perfectly smooth and performant transformation is possible,
^
if
it'd be great, but I don't really think that'd be the case. My
--
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On 2014-06-18 18:46, Tejun Heo wrote:
Hello,
On Tue, Jun 17, 2014 at 05:55:57PM +0200, Paolo Valente wrote:
In general, with both a smooth but messy and a sharp but clean
transformation, there seems to be the following common problems:
1) The main benefits highlighted by Jens, i.e., being
Il giorno 02/giu/2014, alle ore 16:29, Jens Axboe ha scritto:
> On 2014-05-30 23:16, Tejun Heo wrote:
>>> for turning patch #2 into a series of changes for CFQ instead. We need to
>>> end up with something where we can potentially bisect our way down to
>>> whatever caused any given regression.
Il giorno 02/giu/2014, alle ore 16:29, Jens Axboe ax...@kernel.dk ha scritto:
On 2014-05-30 23:16, Tejun Heo wrote:
for turning patch #2 into a series of changes for CFQ instead. We need to
end up with something where we can potentially bisect our way down to
whatever caused any given
At Wed, 11 Jun 2014 22:45:06 +0200,
Paolo Valente wrote:
>
>
> Il giorno 04/giu/2014, alle ore 13:59, Takashi Iwai ha
> scritto:
>
> > […]
> > I've been using BFQ for a while and noticed also some obvious
> > regression in some operations, notably git, too.
> > For example, git grep regresses
At Wed, 11 Jun 2014 22:45:06 +0200,
Paolo Valente wrote:
Il giorno 04/giu/2014, alle ore 13:59, Takashi Iwai ti...@suse.de ha
scritto:
[…]
I've been using BFQ for a while and noticed also some obvious
regression in some operations, notably git, too.
For example, git grep regresses
Il giorno 04/giu/2014, alle ore 13:59, Takashi Iwai ha scritto:
> […]
> I've been using BFQ for a while and noticed also some obvious
> regression in some operations, notably git, too.
> For example, git grep regresses badly.
>
> I ran "test git grep foo > /dev/null" on linux kernel repos on
Il giorno 04/giu/2014, alle ore 12:03, Pavel Machek ha scritto:
> Hi!
>
>> Should this attempt be useless as well, I will, if you do not mind, try by
>> asking you more details about your system and reproducing your configuration
>> as much as I can.
>>
>
> Try making BFQ the default
Il giorno 04/giu/2014, alle ore 12:03, Pavel Machek pa...@ucw.cz ha scritto:
Hi!
Should this attempt be useless as well, I will, if you do not mind, try by
asking you more details about your system and reproducing your configuration
as much as I can.
Try making BFQ the default
Il giorno 04/giu/2014, alle ore 13:59, Takashi Iwai ti...@suse.de ha scritto:
[…]
I've been using BFQ for a while and noticed also some obvious
regression in some operations, notably git, too.
For example, git grep regresses badly.
I ran test git grep foo /dev/null on linux kernel repos
On 2014-06-04 16:31, Pavel Machek wrote:
Hi!
On Mon 2014-06-02 13:33:32, Tejun Heo wrote:
On Mon, Jun 02, 2014 at 01:14:33PM +0200, Pavel Machek wrote:
Now.. I see it is more work for storage maintainers, because there'll
be more code to maintain in the interim. But perhaps user advantages
Hi!
On Mon 2014-06-02 13:33:32, Tejun Heo wrote:
> On Mon, Jun 02, 2014 at 01:14:33PM +0200, Pavel Machek wrote:
> > Now.. I see it is more work for storage maintainers, because there'll
> > be more code to maintain in the interim. But perhaps user advantages
> > are worth it?
>
> I'm quite
On Wed, Jun 04, 2014 at 10:58:29AM -0400, Tejun Heo wrote:
> I think what Jens is planning is something really minimal. Things
> like [cb]fq heavily depend on the old block infrastructure. I don't
> know. Maybe they can be merged in time but I'm not quite sure we'd
> have enough pressure to
On Wed, Jun 04, 2014 at 07:53:30AM -0700, Christoph Hellwig wrote:
> On Wed, Jun 04, 2014 at 10:50:53AM -0400, Tejun Heo wrote:
> > Hmmm... the biggest thing is ioscheds. They heavily rely on being
> > strongly synchronized and are pretty important for rotating rusts.
> > Maybe they can be made
On Wed, Jun 04, 2014 at 10:50:53AM -0400, Tejun Heo wrote:
> Hmmm... the biggest thing is ioscheds. They heavily rely on being
> strongly synchronized and are pretty important for rotating rusts.
> Maybe they can be made to work with blk-mq by forcing single queue or
> something but do we wnat
Hey, Christoph.
On Wed, Jun 04, 2014 at 07:31:36AM -0700, Christoph Hellwig wrote:
> I don't really think there's anything inherently counter productive
> to spinning rust (at least for somewhat modern spinning rust and
> infrastructure) in blk-mq. I'd really like to get rid of the old
> request
On Mon, Jun 02, 2014 at 02:57:30PM -0600, Jens Axboe wrote:
> It's not so much about it being more beneficial to run in blk-mq, as it
> is about not having two code paths. But yes, we're likely going to
> maintain that code for a long time, so it's not going anywhere anytime
> soon.
>
> And for
Il giorno 04/giu/2014, alle ore 13:59, Takashi Iwai ha scritto:
> At Wed, 4 Jun 2014 12:24:30 +0200,
> Paolo Valente wrote:
>>
>>
>> Il giorno 04/giu/2014, alle ore 12:03, Pavel Machek ha
>> scritto:
>>
>>> Hi!
>>>
Should this attempt be useless as well, I will, if you do not mind,
At Wed, 4 Jun 2014 12:24:30 +0200,
Paolo Valente wrote:
>
>
> Il giorno 04/giu/2014, alle ore 12:03, Pavel Machek ha scritto:
>
> > Hi!
> >
> >> Should this attempt be useless as well, I will, if you do not mind, try by
> >> asking you more details about your system and reproducing your
>
Il giorno 04/giu/2014, alle ore 12:03, Pavel Machek ha scritto:
> Hi!
>
>> Should this attempt be useless as well, I will, if you do not mind, try by
>> asking you more details about your system and reproducing your configuration
>> as much as I can.
>>
>
> Try making BFQ the default
Hi!
> Should this attempt be useless as well, I will, if you do not mind, try by
> asking you more details about your system and reproducing your configuration
> as much as I can.
>
Try making BFQ the default scheduler. That seems to break it for me,
when selected at runtime, it looks stable.
Hi!
> Should this attempt be useless as well, I will, if you do not mind,
>try by asking you more details about your system and reproducing your
>configuration as much as I can.
It fails during boot or shortly after that when clicking in gnome2
desktop. I had BFQ as a default scheduler.
Now I
Hi!
> > Like this: I applied patch over today's git...
> >
> > I only see last bits of panic...
> >
> > Call trace:
> > __bfq_bfqq_expire
> > bfq_bfqq_expire
> > bfq_dispatch_requests
> > sci_request_fn
> > ...
> > EIP: T.1839+0x26
> > Any ideas?
> >
>
> We have tried to
Hi!
Like this: I applied patch over today's git...
I only see last bits of panic...
Call trace:
__bfq_bfqq_expire
bfq_bfqq_expire
bfq_dispatch_requests
sci_request_fn
...
EIP: T.1839+0x26
Any ideas?
We have tried to think about ways to trigger
Hi!
Should this attempt be useless as well, I will, if you do not mind,
try by asking you more details about your system and reproducing your
configuration as much as I can.
It fails during boot or shortly after that when clicking in gnome2
desktop. I had BFQ as a default scheduler.
Now I set
Hi!
Should this attempt be useless as well, I will, if you do not mind, try by
asking you more details about your system and reproducing your configuration
as much as I can.
Try making BFQ the default scheduler. That seems to break it for me,
when selected at runtime, it looks stable.
Il giorno 04/giu/2014, alle ore 12:03, Pavel Machek pa...@ucw.cz ha scritto:
Hi!
Should this attempt be useless as well, I will, if you do not mind, try by
asking you more details about your system and reproducing your configuration
as much as I can.
Try making BFQ the default
At Wed, 4 Jun 2014 12:24:30 +0200,
Paolo Valente wrote:
Il giorno 04/giu/2014, alle ore 12:03, Pavel Machek pa...@ucw.cz ha scritto:
Hi!
Should this attempt be useless as well, I will, if you do not mind, try by
asking you more details about your system and reproducing your
Il giorno 04/giu/2014, alle ore 13:59, Takashi Iwai ti...@suse.de ha scritto:
At Wed, 4 Jun 2014 12:24:30 +0200,
Paolo Valente wrote:
Il giorno 04/giu/2014, alle ore 12:03, Pavel Machek pa...@ucw.cz ha
scritto:
Hi!
Should this attempt be useless as well, I will, if you do not
On Mon, Jun 02, 2014 at 02:57:30PM -0600, Jens Axboe wrote:
It's not so much about it being more beneficial to run in blk-mq, as it
is about not having two code paths. But yes, we're likely going to
maintain that code for a long time, so it's not going anywhere anytime
soon.
And for
Hey, Christoph.
On Wed, Jun 04, 2014 at 07:31:36AM -0700, Christoph Hellwig wrote:
I don't really think there's anything inherently counter productive
to spinning rust (at least for somewhat modern spinning rust and
infrastructure) in blk-mq. I'd really like to get rid of the old
request
On Wed, Jun 04, 2014 at 10:50:53AM -0400, Tejun Heo wrote:
Hmmm... the biggest thing is ioscheds. They heavily rely on being
strongly synchronized and are pretty important for rotating rusts.
Maybe they can be made to work with blk-mq by forcing single queue or
something but do we wnat that?
On Wed, Jun 04, 2014 at 07:53:30AM -0700, Christoph Hellwig wrote:
On Wed, Jun 04, 2014 at 10:50:53AM -0400, Tejun Heo wrote:
Hmmm... the biggest thing is ioscheds. They heavily rely on being
strongly synchronized and are pretty important for rotating rusts.
Maybe they can be made to work
On Wed, Jun 04, 2014 at 10:58:29AM -0400, Tejun Heo wrote:
I think what Jens is planning is something really minimal. Things
like [cb]fq heavily depend on the old block infrastructure. I don't
know. Maybe they can be merged in time but I'm not quite sure we'd
have enough pressure to
Hi!
On Mon 2014-06-02 13:33:32, Tejun Heo wrote:
On Mon, Jun 02, 2014 at 01:14:33PM +0200, Pavel Machek wrote:
Now.. I see it is more work for storage maintainers, because there'll
be more code to maintain in the interim. But perhaps user advantages
are worth it?
I'm quite skeptical
On 2014-06-04 16:31, Pavel Machek wrote:
Hi!
On Mon 2014-06-02 13:33:32, Tejun Heo wrote:
On Mon, Jun 02, 2014 at 01:14:33PM +0200, Pavel Machek wrote:
Now.. I see it is more work for storage maintainers, because there'll
be more code to maintain in the interim. But perhaps user advantages
Hi!
> >>> Well, it's all about how to actually route the changes and in general
> >>> whenever avoidable we try to avoid whole-sale code replacement
> >>> especially when most of the structural code is similar like in this
> >>> case. Gradually evolving cfq to bfq is likely to take more work but
Il giorno 02/giu/2014, alle ore 15:02, Pavel Machek ha scritto:
> Hi!
>
>>> Well, it's all about how to actually route the changes and in general
>>> whenever avoidable we try to avoid whole-sale code replacement
>>> especially when most of the structural code is similar like in this
>>> case.
Il giorno 02/giu/2014, alle ore 15:02, Pavel Machek pa...@ucw.cz ha scritto:
Hi!
Well, it's all about how to actually route the changes and in general
whenever avoidable we try to avoid whole-sale code replacement
especially when most of the structural code is similar like in this
case.
Hi!
Well, it's all about how to actually route the changes and in general
whenever avoidable we try to avoid whole-sale code replacement
especially when most of the structural code is similar like in this
case. Gradually evolving cfq to bfq is likely to take more work but
I'm very
On Mon, 2014-06-02 at 13:33 -0400, Tejun Heo wrote:
> Hello, Pavel.
>
> On Mon, Jun 02, 2014 at 01:14:33PM +0200, Pavel Machek wrote:
> > Now.. I see it is more work for storage maintainers, because there'll
> > be more code to maintain in the interim. But perhaps user advantages
> > are worth
On Mon, Jun 02 2014, Tejun Heo wrote:
> Hello,
>
> On Mon, Jun 02, 2014 at 11:46:36AM -0600, Jens Axboe wrote:
> > But blk-mq will potentially drive anything, so it might not be out of
> > the question with a more expensive scheduling variant, if it makes any
> > sense to do of course. At least
Hello,
On Mon, Jun 02, 2014 at 11:46:36AM -0600, Jens Axboe wrote:
> But blk-mq will potentially drive anything, so it might not be out of
> the question with a more expensive scheduling variant, if it makes any
> sense to do of course. At least until there's no more rotating stuff out
> there
On 06/02/2014 11:42 AM, Tejun Heo wrote:
> Hello, Jens.
>
> On Mon, Jun 02, 2014 at 11:32:05AM -0600, Jens Axboe wrote:
>> For things like blkcg, I agree, it should be able to be common code and
>> reusable. But there's a need for scheduling beyond that, for people that
>> don't use control
Hello, Jens.
On Mon, Jun 02, 2014 at 11:32:05AM -0600, Jens Axboe wrote:
> For things like blkcg, I agree, it should be able to be common code and
> reusable. But there's a need for scheduling beyond that, for people that
> don't use control groups (ie most...). And it'd be hard to retrofit cfq
>
Hello, Pavel.
On Mon, Jun 02, 2014 at 01:14:33PM +0200, Pavel Machek wrote:
> Now.. I see it is more work for storage maintainers, because there'll
> be more code to maintain in the interim. But perhaps user advantages
> are worth it?
I'm quite skeptical about going that route. Not necessarily
On 06/02/2014 11:24 AM, Tejun Heo wrote:
> Hello, Jens.
>
> On Mon, Jun 02, 2014 at 08:29:27AM -0600, Jens Axboe wrote:
>> One thing I've neglected to bring up but have been thinking about - we're
>> quickly getting to the point where the old request_fn IO path will become a
>> legacy thing,
Hello, Jens.
On Mon, Jun 02, 2014 at 08:29:27AM -0600, Jens Axboe wrote:
> One thing I've neglected to bring up but have been thinking about - we're
> quickly getting to the point where the old request_fn IO path will become a
> legacy thing, mostly in maintenance mode. That isn't a problem for
On 2014-05-30 23:16, Tejun Heo wrote:
for turning patch #2 into a series of changes for CFQ instead. We need to
end up with something where we can potentially bisect our way down to
whatever caused any given regression. The worst possible situation is "CFQ
works fine for this workload, but BFQ
Hi!
> > Well, it's all about how to actually route the changes and in general
> > whenever avoidable we try to avoid whole-sale code replacement
> > especially when most of the structural code is similar like in this
> > case. Gradually evolving cfq to bfq is likely to take more work but
> > I'm
On Fri 2014-05-30 19:28:04, Tejun Heo wrote:
> Hello,
>
> On Sat, May 31, 2014 at 12:23:01AM +0200, Paolo Valente wrote:
> > I do agree that bfq has essentially the same purpose as cfq. I am
> > not sure that it is what you are proposing, but, in my opinion,
> > since both the engine and all the
On Fri 2014-05-30 19:28:04, Tejun Heo wrote:
Hello,
On Sat, May 31, 2014 at 12:23:01AM +0200, Paolo Valente wrote:
I do agree that bfq has essentially the same purpose as cfq. I am
not sure that it is what you are proposing, but, in my opinion,
since both the engine and all the new
Hi!
Well, it's all about how to actually route the changes and in general
whenever avoidable we try to avoid whole-sale code replacement
especially when most of the structural code is similar like in this
case. Gradually evolving cfq to bfq is likely to take more work but
I'm very
On 2014-05-30 23:16, Tejun Heo wrote:
for turning patch #2 into a series of changes for CFQ instead. We need to
end up with something where we can potentially bisect our way down to
whatever caused any given regression. The worst possible situation is CFQ
works fine for this workload, but BFQ
Hello, Jens.
On Mon, Jun 02, 2014 at 08:29:27AM -0600, Jens Axboe wrote:
One thing I've neglected to bring up but have been thinking about - we're
quickly getting to the point where the old request_fn IO path will become a
legacy thing, mostly in maintenance mode. That isn't a problem for
On 06/02/2014 11:24 AM, Tejun Heo wrote:
Hello, Jens.
On Mon, Jun 02, 2014 at 08:29:27AM -0600, Jens Axboe wrote:
One thing I've neglected to bring up but have been thinking about - we're
quickly getting to the point where the old request_fn IO path will become a
legacy thing, mostly in
Hello, Pavel.
On Mon, Jun 02, 2014 at 01:14:33PM +0200, Pavel Machek wrote:
Now.. I see it is more work for storage maintainers, because there'll
be more code to maintain in the interim. But perhaps user advantages
are worth it?
I'm quite skeptical about going that route. Not necessarily
Hello, Jens.
On Mon, Jun 02, 2014 at 11:32:05AM -0600, Jens Axboe wrote:
For things like blkcg, I agree, it should be able to be common code and
reusable. But there's a need for scheduling beyond that, for people that
don't use control groups (ie most...). And it'd be hard to retrofit cfq
On 06/02/2014 11:42 AM, Tejun Heo wrote:
Hello, Jens.
On Mon, Jun 02, 2014 at 11:32:05AM -0600, Jens Axboe wrote:
For things like blkcg, I agree, it should be able to be common code and
reusable. But there's a need for scheduling beyond that, for people that
don't use control groups (ie
Hello,
On Mon, Jun 02, 2014 at 11:46:36AM -0600, Jens Axboe wrote:
But blk-mq will potentially drive anything, so it might not be out of
the question with a more expensive scheduling variant, if it makes any
sense to do of course. At least until there's no more rotating stuff out
there :-).
On Mon, Jun 02 2014, Tejun Heo wrote:
Hello,
On Mon, Jun 02, 2014 at 11:46:36AM -0600, Jens Axboe wrote:
But blk-mq will potentially drive anything, so it might not be out of
the question with a more expensive scheduling variant, if it makes any
sense to do of course. At least until
On Mon, 2014-06-02 at 13:33 -0400, Tejun Heo wrote:
Hello, Pavel.
On Mon, Jun 02, 2014 at 01:14:33PM +0200, Pavel Machek wrote:
Now.. I see it is more work for storage maintainers, because there'll
be more code to maintain in the interim. But perhaps user advantages
are worth it?
I'm
Hello, Jens.
On Fri, May 30, 2014 at 06:48:54PM -0600, Jens Axboe wrote:
> What I really like about the implementation is, as Tejun highlights, that
> the algorithm is detailed and characterized. Nobody ever wrote any detailed
> documentation on CFQ - I think the closest is a talk I gave at LCA
On 2014-05-30 10:07, Tejun Heo wrote:
We do have multiple ioscheds but sans for anticipatory which pretty
much has been superceded by cfq, they serve different purposes and I'd
really hate the idea of carrying two mostly similar ioscheds in tree.
AS was removed, and exactly for that reason. So
Il giorno 31/mag/2014, alle ore 01:28, Tejun Heo ha scritto:
> Hello,
>
> On Sat, May 31, 2014 at 12:23:01AM +0200, Paolo Valente wrote:
>> I do agree that bfq has essentially the same purpose as cfq. I am
>> not sure that it is what you are proposing, but, in my opinion,
>> since both the
Hello,
On Sat, May 31, 2014 at 12:23:01AM +0200, Paolo Valente wrote:
> I do agree that bfq has essentially the same purpose as cfq. I am
> not sure that it is what you are proposing, but, in my opinion,
> since both the engine and all the new heuristics of bfq differ from
> those of cfq, a
Il giorno 30/mag/2014, alle ore 18:07, Tejun Heo ha scritto:
> Hello, Paolo.
>
> On Thu, May 29, 2014 at 11:05:31AM +0200, Paolo Valente wrote:
>> this patchset introduces the last version of BFQ, a proportional-share
>> storage-I/O scheduler. BFQ also supports hierarchical scheduling with
>>
Hello, Paolo.
On Thu, May 29, 2014 at 11:05:31AM +0200, Paolo Valente wrote:
> this patchset introduces the last version of BFQ, a proportional-share
> storage-I/O scheduler. BFQ also supports hierarchical scheduling with
> a cgroups interface. The first version of BFQ was submitted a few
> years
Hello, Paolo.
On Thu, May 29, 2014 at 11:05:31AM +0200, Paolo Valente wrote:
this patchset introduces the last version of BFQ, a proportional-share
storage-I/O scheduler. BFQ also supports hierarchical scheduling with
a cgroups interface. The first version of BFQ was submitted a few
years ago
Il giorno 30/mag/2014, alle ore 18:07, Tejun Heo t...@kernel.org ha scritto:
Hello, Paolo.
On Thu, May 29, 2014 at 11:05:31AM +0200, Paolo Valente wrote:
this patchset introduces the last version of BFQ, a proportional-share
storage-I/O scheduler. BFQ also supports hierarchical scheduling
Hello,
On Sat, May 31, 2014 at 12:23:01AM +0200, Paolo Valente wrote:
I do agree that bfq has essentially the same purpose as cfq. I am
not sure that it is what you are proposing, but, in my opinion,
since both the engine and all the new heuristics of bfq differ from
those of cfq, a
Il giorno 31/mag/2014, alle ore 01:28, Tejun Heo t...@kernel.org ha scritto:
Hello,
On Sat, May 31, 2014 at 12:23:01AM +0200, Paolo Valente wrote:
I do agree that bfq has essentially the same purpose as cfq. I am
not sure that it is what you are proposing, but, in my opinion,
since both
On 2014-05-30 10:07, Tejun Heo wrote:
We do have multiple ioscheds but sans for anticipatory which pretty
much has been superceded by cfq, they serve different purposes and I'd
really hate the idea of carrying two mostly similar ioscheds in tree.
AS was removed, and exactly for that reason. So
Hello, Jens.
On Fri, May 30, 2014 at 06:48:54PM -0600, Jens Axboe wrote:
What I really like about the implementation is, as Tejun highlights, that
the algorithm is detailed and characterized. Nobody ever wrote any detailed
documentation on CFQ - I think the closest is a talk I gave at LCA in
84 matches
Mail list logo
