All of lore.kernel.org
 help / color / mirror / Atom feed
* scheduling/merging on top of a DM target?
@ 2017-10-22 18:16 Peter Desnoyers
  2017-10-23 10:29 ` Ming Lei
  0 siblings, 1 reply; 2+ messages in thread
From: Peter Desnoyers @ 2017-10-22 18:16 UTC (permalink / raw)
  To: dm-devel

We’re emulating some in-disk algorithms in a device mapper target, and would like to be able to do a fair comparison between the emulated and real versions; however they see radically different I/O streams, evidently because there’s no scheduling / request merging / etc. on top of the bio-based device mapper target.

It appears that if our device mapper were request-based instead of bio-based we wouldn’t have this issue, but after reading a bunch of history on the mailing list archives I don’t think this is going to happen easily.

Does anyone have any thoughts on quick-and-dirty ways to approximate this so we can get some preliminary measurements? dm-multipath won’t stack on a bio-based target, and attempts to stack loopback and various iscsi targets on top haven’t achieved the desired results. (in general these have resulted in our dm target seeing individual 4K I/Os, instead of the larger I/Os at the higher layer)

Thanks,
.....................................................................
 Peter Desnoyers                                  pjd@ccs.neu.edu
 Northeastern Computer & Information Science


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: scheduling/merging on top of a DM target?
  2017-10-22 18:16 scheduling/merging on top of a DM target? Peter Desnoyers
@ 2017-10-23 10:29 ` Ming Lei
  0 siblings, 0 replies; 2+ messages in thread
From: Ming Lei @ 2017-10-23 10:29 UTC (permalink / raw)
  To: Peter Desnoyers; +Cc: open list:DEVICE-MAPPER (LVM)

On Mon, Oct 23, 2017 at 2:16 AM, Peter Desnoyers <pjd@ccs.neu.edu> wrote:
> We’re emulating some in-disk algorithms in a device mapper target, and would like to be able to do a fair comparison between the emulated and real versions; however they see radically different I/O streams, evidently because there’s no scheduling / request merging / etc. on top of the bio-based device mapper target.
>
> It appears that if our device mapper were request-based instead of bio-based we wouldn’t have this issue, but after reading a bunch of history on the mailing list archives I don’t think this is going to happen easily.
>
> Does anyone have any thoughts on quick-and-dirty ways to approximate this so we can get some preliminary measurements? dm-multipath won’t stack on a bio-based target, and attempts to stack loopback and various iscsi targets on top haven’t achieved the desired results. (in general these have resulted in our dm target seeing individual 4K I/Os, instead of the larger I/Os at the higher layer)
>

I posted out one patchset for addressing the issue:

https://marc.info/?l=linux-block&m=150677334021817&w=2

But it has been obsolete, will post out a new version
when I get time to do that.


-- 
Ming Lei

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-10-23 10:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-22 18:16 scheduling/merging on top of a DM target? Peter Desnoyers
2017-10-23 10:29 ` Ming Lei

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.