2007-02-16 11:57:44

by Pierre Ossman

[permalink] [raw]
Subject: Block layer still stack abuser?

I was wondering if the block layer has been changed into a more serialized
manner yet? I've been trying to google this, but so far no luck. I know there
was some talk about removing the stack based approach, but I can't find any
information about where this went.

If it is currently fixed, a pointer to from which version would be nice.

Rgds
--
-- Pierre Ossman

Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org


2007-02-22 02:49:02

by NeilBrown

[permalink] [raw]
Subject: Re: Block layer still stack abuser?

On Friday February 16, [email protected] wrote:
> I was wondering if the block layer has been changed into a more serialized
> manner yet? I've been trying to google this, but so far no luck. I know there
> was some talk about removing the stack based approach, but I can't find any
> information about where this went.
>
> If it is currently fixed, a pointer to from which version would be nice.

Might this:
http://lkml.org/lkml/2007/2/10/22

relate to your question?
If you are talking about stacking block device (via dm or md), then a
patch to fix this in in -mm but there are or were some potential
issues in dm that seem to be holding it up.

NeilBrown

2007-02-22 03:44:44

by Christoph Hellwig

[permalink] [raw]
Subject: Re: Block layer still stack abuser?

On Thu, Feb 22, 2007 at 01:48:00PM +1100, Neil Brown wrote:
> Might this:
> http://lkml.org/lkml/2007/2/10/22
>
> relate to your question?
> If you are talking about stacking block device (via dm or md), then a
> patch to fix this in in -mm but there are or were some potential
> issues in dm that seem to be holding it up.

What are the current blocking issues? There are a lot of users of dm/md
double-stacking (e.g. mirroring + multipath) that are in deep trouble
currently and could be helped greatly with this patch.

2007-02-22 03:47:53

by NeilBrown

[permalink] [raw]
Subject: Re: Block layer still stack abuser?

On Thursday February 22, [email protected] wrote:
> On Thu, Feb 22, 2007 at 01:48:00PM +1100, Neil Brown wrote:
> > Might this:
> > http://lkml.org/lkml/2007/2/10/22
> >
> > relate to your question?
> > If you are talking about stacking block device (via dm or md), then a
> > patch to fix this in in -mm but there are or were some potential
> > issues in dm that seem to be holding it up.
>
> What are the current blocking issues? There are a lot of users of dm/md
> double-stacking (e.g. mirroring + multipath) that are in deep trouble
> currently and could be helped greatly with this patch.

All I know is what is in that mail message that I linked to.

NeilBrown

2007-02-22 05:44:21

by Pierre Ossman

[permalink] [raw]
Subject: Re: Block layer still stack abuser?

Neil Brown wrote:
> On Friday February 16, [email protected] wrote:
>
>> I was wondering if the block layer has been changed into a more serialized
>> manner yet? I've been trying to google this, but so far no luck. I know there
>> was some talk about removing the stack based approach, but I can't find any
>> information about where this went.
>>
>> If it is currently fixed, a pointer to from which version would be nice.
>>
>
> Might this:
> http://lkml.org/lkml/2007/2/10/22
>
> relate to your question?
> If you are talking about stacking block device (via dm or md), then a
> patch to fix this in in -mm but there are or were some potential
> issues in dm that seem to be holding it up.
>
>

Yes, I am. I know there has been general work to reduce stack usage here
and there, but the final suggested solution was to serialize all the
block subsystems so that only one was present on the stack at any given
time.

I was constantly hitting this problem a few years ago when I was running
md+xfs+nfs. The fix was in -mm back then as well. ;)

Rgds

--
-- Pierre Ossman

Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org