> Il giorno 06 nov 2017, alle ore 03:21, Jens Axboe ha
> scritto:
>
> On 11/05/2017 01:39 AM, Paolo Valente wrote:
>>
>>> Il giorno 18 ott 2017, alle ore 15:19, Tejun Heo ha
>>> scritto:
>>>
>>> Hello, Paolo.
>>>
>>> On Tue, Oct 17, 2017 at 12:11:01PM +0200, Paolo Valente wrote:
>>> ...
>>
> Il giorno 06 nov 2017, alle ore 17:39, Jens Axboe ha
> scritto:
>
> On 11/06/2017 09:37 AM, Tejun Heo wrote:
>> On Mon, Nov 06, 2017 at 05:33:45PM +0100, Paolo Valente wrote:
>>>
Il giorno 06 nov 2017, alle ore 17:30, Tejun Heo ha
scritto:
Hello,
On Mon, Nov
On 11/06/2017 09:37 AM, Tejun Heo wrote:
> On Mon, Nov 06, 2017 at 05:33:45PM +0100, Paolo Valente wrote:
>>
>>> Il giorno 06 nov 2017, alle ore 17:30, Tejun Heo ha
>>> scritto:
>>>
>>> Hello,
>>>
>>> On Mon, Nov 06, 2017 at 05:26:38PM +0100, Paolo Valente wrote:
Yes. DEBUG_BLK_CGROUP will
On Mon, Nov 06, 2017 at 05:33:45PM +0100, Paolo Valente wrote:
>
> > Il giorno 06 nov 2017, alle ore 17:30, Tejun Heo ha
> > scritto:
> >
> > Hello,
> >
> > On Mon, Nov 06, 2017 at 05:26:38PM +0100, Paolo Valente wrote:
> >> Yes. DEBUG_BLK_CGROUP will just serve to keep the for-debugging
> >>
> Il giorno 06 nov 2017, alle ore 17:30, Tejun Heo ha scritto:
>
> Hello,
>
> On Mon, Nov 06, 2017 at 05:26:38PM +0100, Paolo Valente wrote:
>> Yes. DEBUG_BLK_CGROUP will just serve to keep the for-debugging
>> subset switched off even when the dynamic parameter is on.
>>
>> We'll wait for po
Hello,
On Mon, Nov 06, 2017 at 05:26:38PM +0100, Paolo Valente wrote:
> Yes. DEBUG_BLK_CGROUP will just serve to keep the for-debugging
> subset switched off even when the dynamic parameter is on.
>
> We'll wait for possible counter-arguments from Tejun, and then start
> to work on what you prop
> Il giorno 06 nov 2017, alle ore 17:22, Jens Axboe ha
> scritto:
>
> On 11/06/2017 09:21 AM, Paolo Valente wrote:
>>
>>> Il giorno 06 nov 2017, alle ore 17:13, Jens Axboe ha
>>> scritto:
>>>
>>> On 11/06/2017 09:11 AM, Paolo Valente wrote:
> Il giorno 06 nov 2017, alle ore 16:47,
On 11/06/2017 09:21 AM, Paolo Valente wrote:
>
>> Il giorno 06 nov 2017, alle ore 17:13, Jens Axboe ha
>> scritto:
>>
>> On 11/06/2017 09:11 AM, Paolo Valente wrote:
>>>
Il giorno 06 nov 2017, alle ore 16:47, Paolo Valente
ha scritto:
>
> Il giorno 06 nov 2017, alle ore
> Il giorno 06 nov 2017, alle ore 17:13, Jens Axboe ha
> scritto:
>
> On 11/06/2017 09:11 AM, Paolo Valente wrote:
>>
>>> Il giorno 06 nov 2017, alle ore 16:47, Paolo Valente
>>> ha scritto:
>>>
Il giorno 06 nov 2017, alle ore 16:00, Tejun Heo ha
scritto:
Hello,
On 11/06/2017 09:11 AM, Paolo Valente wrote:
>
>> Il giorno 06 nov 2017, alle ore 16:47, Paolo Valente
>> ha scritto:
>>
>>>
>>> Il giorno 06 nov 2017, alle ore 16:00, Tejun Heo ha
>>> scritto:
>>>
>>> Hello,
>>>
>>> On Sun, Nov 05, 2017 at 07:21:01PM -0700, Jens Axboe wrote:
It's pointle
> Il giorno 06 nov 2017, alle ore 16:47, Paolo Valente
> ha scritto:
>
>>
>> Il giorno 06 nov 2017, alle ore 16:00, Tejun Heo ha
>> scritto:
>>
>> Hello,
>>
>> On Sun, Nov 05, 2017 at 07:21:01PM -0700, Jens Axboe wrote:
>>> It's pointless to give up on this so soon, when no effort has appa
> Il giorno 06 nov 2017, alle ore 17:03, Jens Axboe ha
> scritto:
>
> On 11/06/2017 08:00 AM, Tejun Heo wrote:
>> Hello,
>>
>> On Sun, Nov 05, 2017 at 07:21:01PM -0700, Jens Axboe wrote:
>>> It's pointless to give up on this so soon, when no effort has apparently
>>> been dedicated to figuring
On 11/06/2017 08:00 AM, Tejun Heo wrote:
> Hello,
>
> On Sun, Nov 05, 2017 at 07:21:01PM -0700, Jens Axboe wrote:
>> It's pointless to give up on this so soon, when no effort has apparently
>> been dedicated to figuring out what the actual issue is yet. So no, no
>> patch that will just disable th
> Il giorno 06 nov 2017, alle ore 16:00, Tejun Heo ha scritto:
>
> Hello,
>
> On Sun, Nov 05, 2017 at 07:21:01PM -0700, Jens Axboe wrote:
>> It's pointless to give up on this so soon, when no effort has apparently
>> been dedicated to figuring out what the actual issue is yet. So no, no
>> patc
Hello,
On Sun, Nov 05, 2017 at 07:21:01PM -0700, Jens Axboe wrote:
> It's pointless to give up on this so soon, when no effort has apparently
> been dedicated to figuring out what the actual issue is yet. So no, no
> patch that will just disable the stats is going to be accepted.
>
> That said, I
> Il giorno 06 nov 2017, alle ore 11:48, Ulf Hansson
> ha scritto:
>
> On 6 November 2017 at 10:49, Paolo Valente wrote:
>>
>>> Il giorno 06 nov 2017, alle ore 10:22, Ulf Hansson
>>> ha scritto:
>>>
>>> On 6 November 2017 at 03:21, Jens Axboe wrote:
On 11/05/2017 01:39 AM, Paolo Vale
On 6 November 2017 at 10:49, Paolo Valente wrote:
>
>> Il giorno 06 nov 2017, alle ore 10:22, Ulf Hansson
>> ha scritto:
>>
>> On 6 November 2017 at 03:21, Jens Axboe wrote:
>>> On 11/05/2017 01:39 AM, Paolo Valente wrote:
> Il giorno 18 ott 2017, alle ore 15:19, Tejun Heo ha
> s
> Il giorno 06 nov 2017, alle ore 10:22, Ulf Hansson
> ha scritto:
>
> On 6 November 2017 at 03:21, Jens Axboe wrote:
>> On 11/05/2017 01:39 AM, Paolo Valente wrote:
>>>
Il giorno 18 ott 2017, alle ore 15:19, Tejun Heo ha
scritto:
Hello, Paolo.
On Tue, Oct 17
On 6 November 2017 at 03:21, Jens Axboe wrote:
> On 11/05/2017 01:39 AM, Paolo Valente wrote:
>>
>>> Il giorno 18 ott 2017, alle ore 15:19, Tejun Heo ha
>>> scritto:
>>>
>>> Hello, Paolo.
>>>
>>> On Tue, Oct 17, 2017 at 12:11:01PM +0200, Paolo Valente wrote:
>>> ...
protected by a per-devic
On 11/05/2017 01:39 AM, Paolo Valente wrote:
>
>> Il giorno 18 ott 2017, alle ore 15:19, Tejun Heo ha
>> scritto:
>>
>> Hello, Paolo.
>>
>> On Tue, Oct 17, 2017 at 12:11:01PM +0200, Paolo Valente wrote:
>> ...
>>> protected by a per-device scheduler lock. To give you an idea, on an
>>> Intel i7
> Il giorno 18 ott 2017, alle ore 15:19, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Tue, Oct 17, 2017 at 12:11:01PM +0200, Paolo Valente wrote:
> ...
>> protected by a per-device scheduler lock. To give you an idea, on an
>> Intel i7-4850HQ, and with 8 threads doing random I/O in parallel
Tejun Heo wrote:
> > The blkg obtained through a blkg_lookup, in a rcu_read section, is
> > protected. But, outside that section, a pointer to that blkg is not
> > guaranteed to be valid any longer. Stat-update functions seem safe in
>
> blkg's destruction is rcu delayed. If you have access t
> Il giorno 21 ott 2017, alle ore 18:13, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Thu, Oct 19, 2017 at 08:50:17AM +0200, Paolo Valente wrote:
>> The blkg obtained through a blkg_lookup, in a rcu_read section, is
>> protected. But, outside that section, a pointer to that blkg is not
>> gu
Hello, Paolo.
On Thu, Oct 19, 2017 at 08:50:17AM +0200, Paolo Valente wrote:
> The blkg obtained through a blkg_lookup, in a rcu_read section, is
> protected. But, outside that section, a pointer to that blkg is not
> guaranteed to be valid any longer. Stat-update functions seem safe in
blkg's
> Il giorno 19 ott 2017, alle ore 08:46, Paolo Valente
> ha scritto:
> ...
>>>
>>> blkgs are, but the blkg_stat objects passed to the blkg_*stat_*
>>> functions by bfq are not. In particular, these objects are contained
>>> in bfq_group objects.
I talked partial nonsense here. bfqg objects a
On 10/18/2017 09:05 AM, Paolo Valente wrote:
>
>> Il giorno 18 ott 2017, alle ore 16:45, Jens Axboe ha
>> scritto:
>>
>> On 10/18/2017 07:19 AM, Tejun Heo wrote:
We tried to understand the reason for this high overhead, and, in
particular, to find out whether whether there was some iss
> Il giorno 18 ott 2017, alle ore 17:08, Paolo Valente
> ha scritto:
>
> Adding again Ulf, Linus and all the others, because Tejun replied to my
> initial email, which did not include them yet as recipients.
>
>> Il giorno 18 ott 2017, alle ore 17:02, Paolo Valente
>> ha scritto:
>>
>>>
>
Adding again Ulf, Linus and all the others, because Tejun replied to my initial
email, which did not include them yet as recipients.
> Il giorno 18 ott 2017, alle ore 17:02, Paolo Valente
> ha scritto:
>
>>
>> Il giorno 18 ott 2017, alle ore 15:19, Tejun Heo ha
>> scritto:
>>
>> Hello, Pao
> Il giorno 18 ott 2017, alle ore 16:45, Jens Axboe ha
> scritto:
>
> On 10/18/2017 07:19 AM, Tejun Heo wrote:
>>> We tried to understand the reason for this high overhead, and, in
>>> particular, to find out whether whether there was some issue that we
>>> could address on our own. But the ca
On 10/18/2017 07:19 AM, Tejun Heo wrote:
>> We tried to understand the reason for this high overhead, and, in
>> particular, to find out whether whether there was some issue that we
>> could address on our own. But the causes seem somehow substantial:
>> one of the most time-consuming operations n
Hello, Paolo.
On Tue, Oct 17, 2017 at 12:11:01PM +0200, Paolo Valente wrote:
...
> protected by a per-device scheduler lock. To give you an idea, on an
> Intel i7-4850HQ, and with 8 threads doing random I/O in parallel on
> null_blk (configured with 0 latency), if the update of groups stats is
>
On 10/17/2017 10:45 AM, Linus Walleij wrote:
> On Tue, Oct 17, 2017 at 2:45 PM, Paolo Valente
> wrote:
>
>> one of the most time-consuming operations needed by some blkg_*stats_*
>> functions is, e.g., find_next_bit, for which we don't see any trivial
>> replacement.
>
> So this is one of the t
On Tue, Oct 17, 2017 at 2:45 PM, Paolo Valente wrote:
> one of the most time-consuming operations needed by some blkg_*stats_*
> functions is, e.g., find_next_bit, for which we don't see any trivial
> replacement.
So this is one of the things that often falls down to a per-arch
assembly optimiza
+Ulf Hansson, Mark Brown, Linus Walleij
> Il giorno 17 ott 2017, alle ore 12:11, Paolo Valente
> ha scritto:
>
> Hi Tejun, all,
> in our work for reducing bfq overhead, we bumped into an unexpected
> fact: the functions blkg_*stats_*, invoked in bfq to update cgroups
> statistics as in cfq, tak
Hi Tejun, all,
in our work for reducing bfq overhead, we bumped into an unexpected
fact: the functions blkg_*stats_*, invoked in bfq to update cgroups
statistics as in cfq, take about 40% of the total execution time of
bfq. This causes an additional serious slowdown on any multicore cpu,
as most b
35 matches
Mail list logo
