Re: [dm-devel] [vdo-devel] [PATCH v2 00/39] Add the dm-vdo deduplication and compression device mapper target.

[Ken Raeburn <raeburn@redhat.com>]

Sweet Tea Dorminy <sweettea-kernel@dorminy.me> writes:

>  There seems a natural duality between
> work items passing between threads, each exclusively owning a
> structure, vs structures passing between threads, each exclusively
> owning a work item. In the first, the threads are grabbing a notional
> 'lock' on each item in turn to deal with their structure, as VDO does
> now; in the second, the threads are grabbing locks on each structure
> in turn to deal with their item.

Yes.

> If kernel workqueues have higher overhead per item for the lightweight
> work VDO currently does in each step, perhaps the dual of the current
> scheme would let more work get done per fixed queuing overhead, and
> thus perform better? VIOs could take locks on sections of structures,
> and operate on multiple structures before requeueing.

Can you suggest a little more specifically what the "dual" is you're
picturing?

[...]
> On the other hand, I played around with switching messagepassing to
> structurelocking in VDO a number of years ago for fun on the side,
> just extremely naively replacing each message passing with releasing a
> mutex on the current set of structures and (trying to) take a mutex on
> the next set of structures, and ran into some complexity around
> certain ordering requirements. I think they were around recovery
> journal entries going into the slab journal and the block map in the
> same order; and also around the use of different priorities for some
> different items. I don't have that code anymore, unfortunately, so I
> don't know how hard it would be to try that experiment again.

Yes, we do have certain ordering requirements in one or two places,
which sort of breaks the mental model of independently processed VIOs.
There are also occasionally non-VIO objects which get queued to invoke
actions on various threads, which I expect might further complicate the
experiment.

Ken

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