Re: [PATCH V3 00/11] block-throttle: add .high limit

[Paolo Valente]

> Il giorno 14 ott 2016, alle ore 20:35, Tejun Heo  ha scritto:
> 
> Hello, Paolo.
> 
> On Fri, Oct 14, 2016 at 07:13:41PM +0200, Paolo Valente wrote:
>> That said, your 'thus' seems a little too strong: "bfq does not yet
>> handle fast SSDs, thus we need something else".  What about the
>> millions of devices (and people) still within 10-20 K IOPS, and
>> experiencing awful latencies and lack of bandwidth guarantees?
> 
> I'm not objecting to any of that.

Ok, sorry for misunderstanding.  I'm just more and more confused about
why a readily available, and not proven wrong solution has not yet
been accepted, if everybody apparently acknowledges the problem.

>  My point just is that bfq, at least
> as currently implemented, is unfit for certain classes of use cases.
> 

Absolutely correct.

>>> FWIW, it looks like the only way we can implement proportional control
>>> on highspeed ssds with acceptable overhead
>> 
>> Maybe not: as I wrote to Viveck in a previous reply, containing
>> pointers to documentation, we have already achieved twenty millions
>> of decisions per second with a prototype driving existing
>> proportional-share packet schedulers (essentially without
>> modifications).
> 
> And that doesn't require idling and thus doesn't severely impact
> utilization?
> 

Nope.  Packets are commonly assumed to be sent asynchronously.
I guess that discussing the validity of this assumption is out of the
scope of this thread.

Thanks,
Paolo

>>> is somehow finding a way to
>>> calculate the cost of each IO and throttle IOs according to that while
>>> controlling for latency as necessary.  Slice scheduling with idling
>>> seems too expensive with highspeed devices with high io depth.
>> 
>> Yes, that's absolutely true.  I'm already thinking about an idleless
>> solution.  As I already wrote, I'm willing to help with scheduling in
>> blk-mq.  I hope there will be the opportunity to find some way to go
>> at KS.
> 
> It'd be great to have a proportional control mechanism whose overhead
> is acceptable.  Unfortunately, we don't have one now and nothing seems
> right around the corner.  (Mostly) work-conserving throttling would be
> fiddlier to use but is something which is useful regardless of such
> proportional control mechanism and can be obtained relatively easily.
> 
> I don't see why the two approaches would be mutually exclusive.
> 
> Thanks.
> 
> -- 
> tejun
> --
> To unsubscribe from this list: send the line "unsubscribe linux-block" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Paolo Valente
Algogroup
Dipartimento di Scienze Fisiche, Informatiche e Matematiche
Via Campi 213/B
41125 Modena - Italy
http://algogroup.unimore.it/people/paolo/





--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Minchan Kim]

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.

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html