[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] A target to just process bios background?

On Tue, 4 Mar 2014, Akira Hayakawa wrote:

> Hi,
> Is it meaningless to submit the split and cloned bios in background
> using workqueue?
> device-mapper doesn't go to next split before the .map hook returns
> (and generic_make_request() returns only in case of DM_MAPIO_REMAPPED).
> So, quitting from .map hook and going into next split fast sounds to me
> effective at least in terms of CPU usage (in multicore system).
> is this discussed before?
> A target as tiny as linear or flakey can be thought:
> - it has work_struct in per_bio_data
> - .map hook queue_work the work into private wq.
> - and then return DM_MAPIO_SUBMITTED
> is this implemented before?
> I think this target will make people happy if they
> want to see what if the bio submission is done background
> without changing their code but only stacking a dm target.
> I am sorry if I am confused.


Such target doesn't exist and I wouldn't recommend to make it. If you 
add the bio to a queue and return immediatelly from the map routine, the 
caller sends another bio. So, in the end, you end up with extreme amount 
of bios on the queue and very bad responsiveness.

Suppose, for example, that you have a system with 16GB memory. 20% can be 
marked dirty (that's the default value for /proc/sys/vm/dirty_ratio), and 
if you use 4k bios, you may have 838860 bios on the queue. Any process 
that tries to write anything to disk freezes until all of them are 

In fact, dm-crypt behaves this way - and we have a bug report that it 
causes out-of-memory crashes when massive amounts of bios are added to the 

dm-mirror also behaves this way, but only for write bios - you can load a 
mirror target with both legs pointing to the same device if you want to 
see how does it behave.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]