Kent,
On Tue, Sep 11, 2012 at 12:31 PM, Kent Overstreet
wrote:
> On Tue, Sep 11, 2012 at 11:58:05AM -0700, Muthu Kumar wrote:
>> On Tue, Sep 11, 2012 at 11:45 AM, Tejun Heo wrote:
>> > Hello,
>> >
>> > On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote:
>> >> Does this preserve the CPU
On Tue, Sep 11, 2012 at 11:58:05AM -0700, Muthu Kumar wrote:
> On Tue, Sep 11, 2012 at 11:45 AM, Tejun Heo wrote:
> > Hello,
> >
> > On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote:
> >> Does this preserve the CPU from which the bio was submitted
> >> originally. Not familiar with
On Tue, Sep 11, 2012 at 11:45 AM, Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote:
>> Does this preserve the CPU from which the bio was submitted
>> originally. Not familiar with cmwq, may be Tejun can clarify.
>>
>> Tejun - the question is, do we honor
Hello,
On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote:
> Does this preserve the CPU from which the bio was submitted
> originally. Not familiar with cmwq, may be Tejun can clarify.
>
> Tejun - the question is, do we honor the rq_affinity with the above
> rescue worker
Kent,
On Mon, Sep 10, 2012 at 2:56 PM, Kent Overstreet wrote:
..
..
>
> +static void bio_alloc_rescue(struct work_struct *work)
> +{
> + struct bio_set *bs = container_of(work, struct bio_set, rescue_work);
> + struct bio *bio;
> +
> + while (1) {
> +
Kent,
On Mon, Sep 10, 2012 at 2:56 PM, Kent Overstreet koverstr...@google.com wrote:
..
snip
..
+static void bio_alloc_rescue(struct work_struct *work)
+{
+ struct bio_set *bs = container_of(work, struct bio_set, rescue_work);
+ struct bio *bio;
+
+ while (1) {
+
Hello,
On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote:
Does this preserve the CPU from which the bio was submitted
originally. Not familiar with cmwq, may be Tejun can clarify.
Tejun - the question is, do we honor the rq_affinity with the above
rescue worker implementation?
On Tue, Sep 11, 2012 at 11:45 AM, Tejun Heo t...@kernel.org wrote:
Hello,
On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote:
Does this preserve the CPU from which the bio was submitted
originally. Not familiar with cmwq, may be Tejun can clarify.
Tejun - the question is, do we
On Tue, Sep 11, 2012 at 11:58:05AM -0700, Muthu Kumar wrote:
On Tue, Sep 11, 2012 at 11:45 AM, Tejun Heo t...@kernel.org wrote:
Hello,
On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote:
Does this preserve the CPU from which the bio was submitted
originally. Not familiar with
Kent,
On Tue, Sep 11, 2012 at 12:31 PM, Kent Overstreet
koverstr...@google.com wrote:
On Tue, Sep 11, 2012 at 11:58:05AM -0700, Muthu Kumar wrote:
On Tue, Sep 11, 2012 at 11:45 AM, Tejun Heo t...@kernel.org wrote:
Hello,
On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote:
Does
On Mon, Sep 10, 2012 at 04:35:02PM -0700, Tejun Heo wrote:
> debug. Would it be difficult to convert dm drivers to collect size
> requirements and use front-pad for all per-bio data?
I can't give a quick answer because a single bio may require a variable
number (depending on the bio content) of
Hello, Alasdair.
On Tue, Sep 11, 2012 at 12:09:17AM +0100, Alasdair G Kergon wrote:
> On Mon, Sep 10, 2012 at 04:01:01PM -0700, Tejun Heo wrote:
> > IIUC, Kent posted a patch which converts all of them to use front-pad
>
> The only patch I saw posted here only handles one of the easier cases so
Hello, again.
On Mon, Sep 10, 2012 at 03:09:10PM -0700, Tejun Heo wrote:
> I'm still a bit scared but think this is correct.
>
> Acked-by: Tejun Heo
>
> One last thing is that we may want to add @name on bioset creation so
> that we can name the workqueue properly but that's for another
On Mon, Sep 10, 2012 at 04:01:01PM -0700, Tejun Heo wrote:
> IIUC, Kent posted a patch which converts all of them to use front-pad
The only patch I saw posted here only handles one of the easier cases so far.
The others are a bit trickier and probably involve a decision about which way to
change
On Mon, Sep 10, 2012 at 04:01:01PM -0700, Tejun Heo wrote:
> Hello,
>
> On Mon, Sep 10, 2012 at 3:50 PM, Alasdair G Kergon wrote:
> >> > Note that this doesn't do anything for allocation from other
> >> > mempools.
> >
> > Note that dm has several cases of this, so this patch should not be
On Mon, Sep 10, 2012 at 11:50:57PM +0100, Alasdair G Kergon wrote:
> On Mon, Sep 10, 2012 at 03:09:10PM -0700, Tejun Heo wrote:
> > On Mon, Sep 10, 2012 at 02:56:33PM -0700, Kent Overstreet wrote:
> > > commit df7e63cbffa3065fcc4ba2b9a93418d7c7312243
> > > Author: Kent Overstreet
> > > Date:
Hello,
On Mon, Sep 10, 2012 at 3:50 PM, Alasdair G Kergon wrote:
>> > Note that this doesn't do anything for allocation from other mempools.
>
> Note that dm has several cases of this, so this patch should not be used with
> dm yet. Mikulas is studying those cases to see whether anything
On Mon, Sep 10, 2012 at 03:09:10PM -0700, Tejun Heo wrote:
> On Mon, Sep 10, 2012 at 02:56:33PM -0700, Kent Overstreet wrote:
> > commit df7e63cbffa3065fcc4ba2b9a93418d7c7312243
> > Author: Kent Overstreet
> > Date: Mon Sep 10 14:33:46 2012 -0700
> >
> > block: Avoid deadlocks with bio
Hello, Kent.
On Mon, Sep 10, 2012 at 02:56:33PM -0700, Kent Overstreet wrote:
> commit df7e63cbffa3065fcc4ba2b9a93418d7c7312243
> Author: Kent Overstreet
> Date: Mon Sep 10 14:33:46 2012 -0700
>
> block: Avoid deadlocks with bio allocation by stacking drivers
>
> Previously, if
On Mon, Sep 10, 2012 at 02:37:10PM -0700, Tejun Heo wrote:
> On Mon, Sep 10, 2012 at 02:33:49PM -0700, Kent Overstreet wrote:
> > "Simpler" isn't really an objective thing though. To me the goto version
> > is more obvious/idiomatic.
> >
> > Eh. I'll do it your way, but consider this a formal
On Mon, Sep 10, 2012 at 02:33:49PM -0700, Kent Overstreet wrote:
> "Simpler" isn't really an objective thing though. To me the goto version
> is more obvious/idiomatic.
>
> Eh. I'll do it your way, but consider this a formal objection :p
Thanks. :)
--
tejun
--
To unsubscribe from this list:
On Mon, Sep 10, 2012 at 01:40:10PM -0700, Tejun Heo wrote:
> Hello, Kent.
>
> On Mon, Sep 10, 2012 at 01:24:35PM -0700, Kent Overstreet wrote:
> > And at that point, why duplicate that line of code? It doesn't matter that
> > much, but IMO a goto retry better labels what's actually going on (it's
Hello, Kent.
On Mon, Sep 10, 2012 at 01:24:35PM -0700, Kent Overstreet wrote:
> And at that point, why duplicate that line of code? It doesn't matter that
> much, but IMO a goto retry better labels what's actually going on (it's
> something that's not uncommon in the kernel and if I see a retry
On Mon, Sep 10, 2012 at 10:22:10AM -0700, Tejun Heo wrote:
> Hello, Kent.
>
> On Sun, Sep 09, 2012 at 05:28:10PM -0700, Kent Overstreet wrote:
> > > > + while ((bio = bio_list_pop(current->bio_list)))
> > > > + bio_list_add(bio->bi_pool == bs ? : , bio);
> > > > +
> > > > +
Hello, Kent.
On Sun, Sep 09, 2012 at 05:28:10PM -0700, Kent Overstreet wrote:
> > > + while ((bio = bio_list_pop(current->bio_list)))
> > > + bio_list_add(bio->bi_pool == bs ? : , bio);
> > > +
> > > + *current->bio_list = nopunt;
> >
> > Why this is necessary needs explanation and it's
On Sun, Sep 09, 2012 at 05:28:10PM -0700, Kent Overstreet wrote:
[..]
> > > +retry:
> > > p = mempool_alloc(bs->bio_pool, gfp_mask);
> > > front_pad = bs->front_pad;
> > > inline_vecs = BIO_INLINE_VECS;
> > > }
> >
> > Wouldn't the following be better?
> >
> >
On Sun, Sep 09, 2012 at 05:28:10PM -0700, Kent Overstreet wrote:
[..]
+retry:
p = mempool_alloc(bs-bio_pool, gfp_mask);
front_pad = bs-front_pad;
inline_vecs = BIO_INLINE_VECS;
}
Wouldn't the following be better?
p =
Hello, Kent.
On Sun, Sep 09, 2012 at 05:28:10PM -0700, Kent Overstreet wrote:
+ while ((bio = bio_list_pop(current-bio_list)))
+ bio_list_add(bio-bi_pool == bs ? punt : nopunt, bio);
+
+ *current-bio_list = nopunt;
Why this is necessary needs explanation and it's done in
On Mon, Sep 10, 2012 at 10:22:10AM -0700, Tejun Heo wrote:
Hello, Kent.
On Sun, Sep 09, 2012 at 05:28:10PM -0700, Kent Overstreet wrote:
+ while ((bio = bio_list_pop(current-bio_list)))
+ bio_list_add(bio-bi_pool == bs ? punt : nopunt, bio);
+
+
Hello, Kent.
On Mon, Sep 10, 2012 at 01:24:35PM -0700, Kent Overstreet wrote:
And at that point, why duplicate that line of code? It doesn't matter that
much, but IMO a goto retry better labels what's actually going on (it's
something that's not uncommon in the kernel and if I see a retry
On Mon, Sep 10, 2012 at 01:40:10PM -0700, Tejun Heo wrote:
Hello, Kent.
On Mon, Sep 10, 2012 at 01:24:35PM -0700, Kent Overstreet wrote:
And at that point, why duplicate that line of code? It doesn't matter that
much, but IMO a goto retry better labels what's actually going on (it's
On Mon, Sep 10, 2012 at 02:33:49PM -0700, Kent Overstreet wrote:
Simpler isn't really an objective thing though. To me the goto version
is more obvious/idiomatic.
Eh. I'll do it your way, but consider this a formal objection :p
Thanks. :)
--
tejun
--
To unsubscribe from this list: send the
On Mon, Sep 10, 2012 at 02:37:10PM -0700, Tejun Heo wrote:
On Mon, Sep 10, 2012 at 02:33:49PM -0700, Kent Overstreet wrote:
Simpler isn't really an objective thing though. To me the goto version
is more obvious/idiomatic.
Eh. I'll do it your way, but consider this a formal objection :p
Hello, Kent.
On Mon, Sep 10, 2012 at 02:56:33PM -0700, Kent Overstreet wrote:
commit df7e63cbffa3065fcc4ba2b9a93418d7c7312243
Author: Kent Overstreet koverstr...@google.com
Date: Mon Sep 10 14:33:46 2012 -0700
block: Avoid deadlocks with bio allocation by stacking drivers
On Mon, Sep 10, 2012 at 03:09:10PM -0700, Tejun Heo wrote:
On Mon, Sep 10, 2012 at 02:56:33PM -0700, Kent Overstreet wrote:
commit df7e63cbffa3065fcc4ba2b9a93418d7c7312243
Author: Kent Overstreet koverstr...@google.com
Date: Mon Sep 10 14:33:46 2012 -0700
block: Avoid deadlocks
Hello,
On Mon, Sep 10, 2012 at 3:50 PM, Alasdair G Kergon a...@redhat.com wrote:
Note that this doesn't do anything for allocation from other mempools.
Note that dm has several cases of this, so this patch should not be used with
dm yet. Mikulas is studying those cases to see whether
On Mon, Sep 10, 2012 at 11:50:57PM +0100, Alasdair G Kergon wrote:
On Mon, Sep 10, 2012 at 03:09:10PM -0700, Tejun Heo wrote:
On Mon, Sep 10, 2012 at 02:56:33PM -0700, Kent Overstreet wrote:
commit df7e63cbffa3065fcc4ba2b9a93418d7c7312243
Author: Kent Overstreet koverstr...@google.com
On Mon, Sep 10, 2012 at 04:01:01PM -0700, Tejun Heo wrote:
Hello,
On Mon, Sep 10, 2012 at 3:50 PM, Alasdair G Kergon a...@redhat.com wrote:
Note that this doesn't do anything for allocation from other
mempools.
Note that dm has several cases of this, so this patch should not be
On Mon, Sep 10, 2012 at 04:01:01PM -0700, Tejun Heo wrote:
IIUC, Kent posted a patch which converts all of them to use front-pad
The only patch I saw posted here only handles one of the easier cases so far.
The others are a bit trickier and probably involve a decision about which way to
change
Hello, again.
On Mon, Sep 10, 2012 at 03:09:10PM -0700, Tejun Heo wrote:
I'm still a bit scared but think this is correct.
Acked-by: Tejun Heo t...@kernel.org
One last thing is that we may want to add @name on bioset creation so
that we can name the workqueue properly but that's for
Hello, Alasdair.
On Tue, Sep 11, 2012 at 12:09:17AM +0100, Alasdair G Kergon wrote:
On Mon, Sep 10, 2012 at 04:01:01PM -0700, Tejun Heo wrote:
IIUC, Kent posted a patch which converts all of them to use front-pad
The only patch I saw posted here only handles one of the easier cases so far.
On Mon, Sep 10, 2012 at 04:35:02PM -0700, Tejun Heo wrote:
debug. Would it be difficult to convert dm drivers to collect size
requirements and use front-pad for all per-bio data?
I can't give a quick answer because a single bio may require a variable
number (depending on the bio content) of
On Sat, Sep 08, 2012 at 12:36:41PM -0700, Tejun Heo wrote:
> (Restoring cc list from the previous discussion. Please retain the cc
> list of the people who discussed in the previous postings.)
>
> On Fri, Sep 07, 2012 at 03:12:53PM -0700, Kent Overstreet wrote:
> > But this is tricky and not a
On Sat, Sep 08, 2012 at 12:36:41PM -0700, Tejun Heo wrote:
(Restoring cc list from the previous discussion. Please retain the cc
list of the people who discussed in the previous postings.)
On Fri, Sep 07, 2012 at 03:12:53PM -0700, Kent Overstreet wrote:
But this is tricky and not a generic
(Restoring cc list from the previous discussion. Please retain the cc
list of the people who discussed in the previous postings.)
On Fri, Sep 07, 2012 at 03:12:53PM -0700, Kent Overstreet wrote:
> But this is tricky and not a generic solution. This patch solves it for
> all users by inverting
(Restoring cc list from the previous discussion. Please retain the cc
list of the people who discussed in the previous postings.)
On Fri, Sep 07, 2012 at 03:12:53PM -0700, Kent Overstreet wrote:
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be
48 matches
Mail list logo
