Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

Thanks! On Tue, Mar 28, 2017 at 2:59 PM, Jens Axboe wrote: > On 03/09/2017 01:05 AM, Tahsin Erdogan wrote: >> blkg_conf_prep() currently calls blkg_lookup_create() while holding >> request queue spinlock. This means allocating memory for struct >> blkcg_gq has to be made

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

Thanks! On Tue, Mar 28, 2017 at 2:59 PM, Jens Axboe wrote: > On 03/09/2017 01:05 AM, Tahsin Erdogan wrote: >> blkg_conf_prep() currently calls blkg_lookup_create() while holding >> request queue spinlock. This means allocating memory for struct >> blkcg_gq has to be made non-blocking. This

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

On 03/09/2017 01:05 AM, Tahsin Erdogan wrote: > blkg_conf_prep() currently calls blkg_lookup_create() while holding > request queue spinlock. This means allocating memory for struct > blkcg_gq has to be made non-blocking. This causes occasional -ENOMEM > failures in call paths like below: > >

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

On 03/09/2017 01:05 AM, Tahsin Erdogan wrote: > blkg_conf_prep() currently calls blkg_lookup_create() while holding > request queue spinlock. This means allocating memory for struct > blkcg_gq has to be made non-blocking. This causes occasional -ENOMEM > failures in call paths like below: > >

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

>> Do you mean, you prefer the approach that was taken in v1 patch or >> something else? > > I can no longer find v1 of the patch, just v2 and on. Can you send a > link to it? https://lkml.org/lkml/2017/2/28/8

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

>> Do you mean, you prefer the approach that was taken in v1 patch or >> something else? > > I can no longer find v1 of the patch, just v2 and on. Can you send a > link to it? https://lkml.org/lkml/2017/2/28/8

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

On 03/11/2017 09:35 PM, Tahsin Erdogan wrote: > On Sat, Mar 11, 2017 at 2:52 PM, Jens Axboe wrote: > >> >> Talked to Tejun about this as well, and we both agree that the splitting >> this into separate init/alloc paths would be much cleaner. I can't >> apply the current patch,

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

On 03/11/2017 09:35 PM, Tahsin Erdogan wrote: > On Sat, Mar 11, 2017 at 2:52 PM, Jens Axboe wrote: > >> >> Talked to Tejun about this as well, and we both agree that the splitting >> this into separate init/alloc paths would be much cleaner. I can't >> apply the current patch, sorry, it's just

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

On Sat, Mar 11, 2017 at 2:52 PM, Jens Axboe wrote: > > Talked to Tejun about this as well, and we both agree that the splitting > this into separate init/alloc paths would be much cleaner. I can't > apply the current patch, sorry, it's just too ugly to live. Do you mean, you

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

On Sat, Mar 11, 2017 at 2:52 PM, Jens Axboe wrote: > > Talked to Tejun about this as well, and we both agree that the splitting > this into separate init/alloc paths would be much cleaner. I can't > apply the current patch, sorry, it's just too ugly to live. Do you mean, you prefer the approach

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

On 03/11/2017 03:42 PM, Jens Axboe wrote: >> @@ -185,31 +187,53 @@ static struct blkcg_gq *blkg_create(struct blkcg >> *blkcg, >> goto err_free_blkg; >> } >> >> +if (drop_locks) { >> +spin_unlock_irq(q->queue_lock); >> +rcu_read_unlock(); >> +}

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

On 03/11/2017 03:42 PM, Jens Axboe wrote: >> @@ -185,31 +187,53 @@ static struct blkcg_gq *blkg_create(struct blkcg >> *blkcg, >> goto err_free_blkg; >> } >> >> +if (drop_locks) { >> +spin_unlock_irq(q->queue_lock); >> +rcu_read_unlock(); >> +}

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

> @@ -185,31 +187,53 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg, > goto err_free_blkg; > } > > + if (drop_locks) { > + spin_unlock_irq(q->queue_lock); > + rcu_read_unlock(); > + } I have a general dislike for code like that,

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

> @@ -185,31 +187,53 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg, > goto err_free_blkg; > } > > + if (drop_locks) { > + spin_unlock_irq(q->queue_lock); > + rcu_read_unlock(); > + } I have a general dislike for code like that,

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

On Thu, Mar 09, 2017 at 12:05:31AM -0800, Tahsin Erdogan wrote: > blkg_conf_prep() currently calls blkg_lookup_create() while holding > request queue spinlock. This means allocating memory for struct > blkcg_gq has to be made non-blocking. This causes occasional -ENOMEM > failures in call paths

Re: [PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

On Thu, Mar 09, 2017 at 12:05:31AM -0800, Tahsin Erdogan wrote: > blkg_conf_prep() currently calls blkg_lookup_create() while holding > request queue spinlock. This means allocating memory for struct > blkcg_gq has to be made non-blocking. This causes occasional -ENOMEM > failures in call paths

[PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

blkg_conf_prep() currently calls blkg_lookup_create() while holding request queue spinlock. This means allocating memory for struct blkcg_gq has to be made non-blocking. This causes occasional -ENOMEM failures in call paths like below: pcpu_alloc+0x68f/0x710 __alloc_percpu_gfp+0xd/0x10

[PATCH v5] blkcg: allocate struct blkcg_gq outside request queue spinlock

blkg_conf_prep() currently calls blkg_lookup_create() while holding request queue spinlock. This means allocating memory for struct blkcg_gq has to be made non-blocking. This causes occasional -ENOMEM failures in call paths like below: pcpu_alloc+0x68f/0x710 __alloc_percpu_gfp+0xd/0x10