Hello Minchan, On (10/17/16 14:04), Minchan Kim wrote: > Hi Sergey, > > On Fri, Oct 07, 2016 at 03:33:22PM +0900, Minchan Kim wrote: > > < snip > > > > > so the question is -- can we move this parallelization out of zram > > > and instead flush bdi in more than one kthread? how bad that would > > > be? can anyone else benefit from this? > > > > Isn't it blk-mq you mentioned? With blk-mq, I have some concerns. > > > > 1. read speed degradation > > 2. no work with rw_page > > 3. more memory footprint by bio/request queue allocation > > > > Having said, it's worth to look into it in detail more. > > I will have time to see that approach to know what I can do > > with that. > > queue_mode=2 bs=4096 nr_devices=1 submit_queues=4 hw_queue_depth=128 > > Last week, I played with null_blk and blk-mq.c to get an idea how > blk-mq works and I realized it's not good for zram because it aims > to solve 1) dispatch queue bottleneck 2) cache-friendly IO completion > through IRQ so 3) avoids remote memory accesses. > > For zram which is used for embedded as primary purpose, ones listed > abvoe are not a severe problem. Most imporant thing is there is no > model to support that a process queueing IO request on *a* CPU while > other CPUs issues the queued IO to driver. > > Anyway, Although blk-mrq can support that model, it is blk-layer thing. > IOW, it's software stuff for fast IO delievry but what we need is > device parallelism of zram itself. So, although we follow blk-mq, > we still need multiple threads to compress in parallel which is most of > code I wrote in this patchset. yes. but at least wb can be multi-threaded. well, sort of. seems like. sometimes. > If I cannot get huge benefit(e.g., reduce a lot of zram-speicif code > to support such model) with blk-mq, I don't feel to switch to request > model at the cost of reasons I stated above. thanks. I'm looking at your patches. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
