On Mon, Jan 17 2022 at 3:10P -0500,
Christoph Hellwig wrote:
> On Tue, Jan 11, 2022 at 01:23:53PM -0500, Jeff Moyer wrote:
> > Maybe I have bad taste, but the patches didn't look like cruft to me.
> > :)
>
> They do to me. The extend the corner case of request on request
> stacking that
On Tue, Jan 11, 2022 at 01:23:53PM -0500, Jeff Moyer wrote:
> Maybe I have bad taste, but the patches didn't look like cruft to me.
> :)
They do to me. The extend the corner case of request on request
stacking that already is a bit of mess even more by adding yet another
special case in the
On Tue, Jan 11, 2022 at 11:15:09AM -0500, Mike Snitzer wrote:
> Round and round we go.. Pretty tired of this.
Same here.
> You are perfectly fine with incrementally compromising request-based
> DM's ability to evolve as block core does.
I would not word it that way, but I think we mean the same
Christoph Hellwig writes:
> On Tue, Dec 28, 2021 at 04:30:08PM -0500, Mike Snitzer wrote:
>> Yeah, people use request-based for IO scheduling and more capable path
>> selectors. Imposing bio-based would be a pretty jarring workaround for
>> BLK_MQ_F_BLOCKING. request-based DM should properly
On Tue, Jan 11 2022 at 3:34P -0500,
Christoph Hellwig wrote:
> On Tue, Dec 28, 2021 at 04:30:08PM -0500, Mike Snitzer wrote:
> > Yeah, people use request-based for IO scheduling and more capable path
> > selectors. Imposing bio-based would be a pretty jarring workaround for
> >
On Tue, Dec 28, 2021 at 04:30:08PM -0500, Mike Snitzer wrote:
> Yeah, people use request-based for IO scheduling and more capable path
> selectors. Imposing bio-based would be a pretty jarring workaround for
> BLK_MQ_F_BLOCKING. request-based DM should properly support it.
Given that nvme-tcp is
On Tue, Dec 28 2021 at 4:30P -0500,
Mike Snitzer wrote:
> On Wed, Dec 22 2021 at 11:16P -0500,
> Ming Lei wrote:
>
> > On Tue, Dec 21, 2021 at 08:21:39AM -0800, Christoph Hellwig wrote:
> > > On Tue, Dec 21, 2021 at 10:14:56PM +0800, Ming Lei wrote:
> > > > Hello,
> > > >
> > > > dm-rq may
On Wed, Dec 22 2021 at 11:16P -0500,
Ming Lei wrote:
> On Tue, Dec 21, 2021 at 08:21:39AM -0800, Christoph Hellwig wrote:
> > On Tue, Dec 21, 2021 at 10:14:56PM +0800, Ming Lei wrote:
> > > Hello,
> > >
> > > dm-rq may be built on blk-mq device which marks BLK_MQ_F_BLOCKING, so
> > >
On Tue, Dec 21, 2021 at 08:21:39AM -0800, Christoph Hellwig wrote:
> On Tue, Dec 21, 2021 at 10:14:56PM +0800, Ming Lei wrote:
> > Hello,
> >
> > dm-rq may be built on blk-mq device which marks BLK_MQ_F_BLOCKING, so
> > dm_mq_queue_rq() may become to sleep current context.
> >
> > Fixes the
On Tue, Dec 21, 2021 at 10:14:56PM +0800, Ming Lei wrote:
> Hello,
>
> dm-rq may be built on blk-mq device which marks BLK_MQ_F_BLOCKING, so
> dm_mq_queue_rq() may become to sleep current context.
>
> Fixes the issue by allowing dm-rq to set BLK_MQ_F_BLOCKING in case that
> any underlying queue
Hello,
dm-rq may be built on blk-mq device which marks BLK_MQ_F_BLOCKING, so
dm_mq_queue_rq() may become to sleep current context.
Fixes the issue by allowing dm-rq to set BLK_MQ_F_BLOCKING in case that
any underlying queue is marked as BLK_MQ_F_BLOCKING.
DM request queue is allocated before
11 matches
Mail list logo
