Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1505486

Re: [PATCH 2/3] zram: support page-based parallel write

From Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Newsgroups linux.kernel
Subject Re: [PATCH 2/3] zram: support page-based parallel write
Date 2016-10-21 08:10 +0200
Message-ID <suBbH-1G3-3@gated-at.bofh.it> (permalink)
References (4 earlier) <sopPY-648-9@gated-at.bofh.it> <soJOF-2Cq-1@gated-at.bofh.it> <spcdX-60e-17@gated-at.bofh.it> <spwZ3-4CN-5@gated-at.bofh.it> <st8lr-7wj-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH 2/3] zram: support page-based parallel write Minchan Kim <minchan@kernel.org> - 2016-10-17 07:10 +0200
  Re: [PATCH 2/3] zram: support page-based parallel write Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-10-21 08:10 +0200
    Re: [PATCH 2/3] zram: support page-based parallel write Minchan Kim <minchan@kernel.org> - 2016-10-24 07:00 +0200

csiph-web