On 06/08/2017 09:30 AM, Paolo Valente wrote:
>
>> Il giorno 05 giu 2017, alle ore 10:11, Paolo Valente
>> ha scritto:
>>
>> In blk-cgroup, operations on blkg objects are protected with the
>> request_queue lock. This is no more the lock that protects
>> I/O-scheduler operations in blk-mq. In fac
> Il giorno 05 giu 2017, alle ore 10:11, Paolo Valente
> ha scritto:
>
> In blk-cgroup, operations on blkg objects are protected with the
> request_queue lock. This is no more the lock that protects
> I/O-scheduler operations in blk-mq. In fact, the latter are now
> protected with a finer-grain
In blk-cgroup, operations on blkg objects are protected with the
request_queue lock. This is no more the lock that protects
I/O-scheduler operations in blk-mq. In fact, the latter are now
protected with a finer-grained per-scheduler-instance lock. As a
consequence, although blkg lookups are also rc
Hello, Paolo.
On Thu, May 25, 2017 at 09:10:59AM +0200, Paolo Valente wrote:
> Ok. So, just to better understand: as of now, i.e., before you make
> the changes you are proposing, the address returned by blkg_lookup can
> be used safely only if one both invokes blkg_lookup and gets a
> reference,
> Il giorno 24 mag 2017, alle ore 17:47, Tejun Heo ha scritto:
>
> Hello,
>
> On Wed, May 24, 2017 at 05:43:18PM +0100, Paolo Valente wrote:
>>> so none of the above objects can be destroyed before the request is
>>> done.
>>
>> ... the issue seems just to move to a more subtle position: cfq i
Hello,
On Wed, May 24, 2017 at 05:43:18PM +0100, Paolo Valente wrote:
> > so none of the above objects can be destroyed before the request is
> > done.
>
> ... the issue seems just to move to a more subtle position: cfq is ok,
> because it protects itself with rq lock, but blk-mq schedulers don't
> Il giorno 24 mag 2017, alle ore 15:50, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Wed, May 24, 2017 at 12:53:26PM +0100, Paolo Valente wrote:
>> Exact, but even after all blkgs, as well as the cfq_group and pd, are
>> gone, the children cfq_queues of the gone cfq_group continue to point
>
Hello, Paolo.
On Wed, May 24, 2017 at 12:53:26PM +0100, Paolo Valente wrote:
> Exact, but even after all blkgs, as well as the cfq_group and pd, are
> gone, the children cfq_queues of the gone cfq_group continue to point
> to unexisting objects, until new cfq_set_requests are executed for
> those
> Il giorno 24 mag 2017, alle ore 12:53, Paolo Valente
> ha scritto:
>
>>
>> Il giorno 23 mag 2017, alle ore 21:42, Tejun Heo ha
>> scritto:
>>
>> Hello, Paolo.
>>
>> On Sat, May 20, 2017 at 09:27:33AM +0200, Paolo Valente wrote:
>>> Consider a process or a group that is moved from a given
> Il giorno 23 mag 2017, alle ore 21:42, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Sat, May 20, 2017 at 09:27:33AM +0200, Paolo Valente wrote:
>> Consider a process or a group that is moved from a given source group
>> to a different group, or simply removed from a group (although I
>> did
Hello, Paolo.
On Sat, May 20, 2017 at 09:27:33AM +0200, Paolo Valente wrote:
> Consider a process or a group that is moved from a given source group
> to a different group, or simply removed from a group (although I
> didn't yet succeed in just removing a process from a group :) ). The
> pointer
> Il giorno 19 mag 2017, alle ore 16:37, Jens Axboe ha
> scritto:
>
> On 05/19/2017 02:39 AM, Paolo Valente wrote:
>> @@ -692,8 +725,7 @@ void bfq_pd_offline(struct blkg_policy_data *pd)
>> /*
>> * The idle tree may still contain bfq_queues belonging
>>
> Il giorno 19 mag 2017, alle ore 16:54, Tejun Heo ha scritto:
>
> Hello, Paolo.
>
> On Fri, May 19, 2017 at 10:39:08AM +0200, Paolo Valente wrote:
>> Operations on blkg objects in blk-cgroup are protected with the
>> request_queue lock, which is no more the lock that protects
>> I/O-scheduler
Hello, Paolo.
On Fri, May 19, 2017 at 10:39:08AM +0200, Paolo Valente wrote:
> Operations on blkg objects in blk-cgroup are protected with the
> request_queue lock, which is no more the lock that protects
> I/O-scheduler operations in blk-mq. The latter are now protected with
> finer-grained per-s
On 05/19/2017 02:39 AM, Paolo Valente wrote:
> @@ -692,8 +725,7 @@ void bfq_pd_offline(struct blkg_policy_data *pd)
> /*
>* The idle tree may still contain bfq_queues belonging
>* to exited task because they never migrated to a different
> -
Operations on blkg objects in blk-cgroup are protected with the
request_queue lock, which is no more the lock that protects
I/O-scheduler operations in blk-mq. The latter are now protected with
finer-grained per-scheduler-instance locks. As a consequence, if blkg
and blkg-related objects are access
16 matches
Mail list logo