> Il giorno 14 ott 2016, alle ore 20:35, Tejun Heo <tj@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
