Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1554655
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH V5 05/17] blk-throttle: add upgrade logic for LIMIT_LOW state |
| Date | 2017-01-09 20:50 +0100 |
| Message-ID | <sXO78-8iZ-33@gated-at.bofh.it> (permalink) |
| References | <sOKYO-1X6-11@gated-at.bofh.it> <sOKYO-1X6-15@gated-at.bofh.it> <sXNb3-7Kn-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hello, again. On Mon, Jan 09, 2017 at 01:40:53PM -0500, Tejun Heo wrote: > I think it'd be great to explain the above. It was a bit difficult > for me to follow. It's also interesting because we're tying state > transitions for both read and write together. blk-throtl has been > handling reads and writes independently, now the mode switching from > low to max is shared across reads and writes. I suppose it could be > fine but would it be complex to separate them out? It's weird to make > this one state shared across reads and writes while not for others or > was this sharing intentional? I thought more about it and as the low limit is regulated by latency, it makes sense to make the state shared across reads and writes; otherwise, IOs in one direction could easily mess up the other direction. Can you please document that this is an intentional design and explain the rationale tho? Thanks. -- tejun
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [PATCH V5 05/17] blk-throttle: add upgrade logic for LIMIT_LOW state Tejun Heo <tj@kernel.org> - 2017-01-09 19:50 +0100 Re: [PATCH V5 05/17] blk-throttle: add upgrade logic for LIMIT_LOW state Tejun Heo <tj@kernel.org> - 2017-01-09 20:50 +0100
csiph-web