Re: About the try to remove cross-release feature entirely by Ingo

2017-12-28 Thread Byungchul Park
On Thu, Dec 28, 2017 at 10:51:46PM -0500, Theodore Ts'o wrote: > On Fri, Dec 29, 2017 at 10:47:36AM +0900, Byungchul Park wrote: > > > >(1) The best way: To classify all waiters correctly. > > It's really not all waiters, but all *locks*, no? Thanks for your opinion. I will add my opinion

Re: About the try to remove cross-release feature entirely by Ingo

2017-12-28 Thread Theodore Ts'o
On Fri, Dec 29, 2017 at 10:47:36AM +0900, Byungchul Park wrote: > >(1) The best way: To classify all waiters correctly. It's really not all waiters, but all *locks*, no? > Ultimately the problems should be solved in this way. But it > takes a lot of time so it's not easy to use

Re: About the try to remove cross-release feature entirely by Ingo

2017-12-28 Thread Byungchul Park
On Fri, Dec 29, 2017 at 10:47:36AM +0900, Byungchul Park wrote: > On Wed, Dec 13, 2017 at 03:24:29PM +0900, Byungchul Park wrote: > > Lockdep works, based on the following: > > > >(1) Classifying locks properly > >(2) Checking relationship between the classes > > > > If (1) is not good

Re: [for-416 PATCH v2] bcache: writeback: collapse contiguous IO better

2017-12-28 Thread tang . junhui
From: Tang Junhui LGTM, I would like it much more if MAX_WRITEBACKS_IN_PASS(5) defines a little bigger value. Reviewed-by: Tang Junhui >Previously, there was some logic that attempted to immediately issue >writeback of backing-contiguous blocks

Re: About the try to remove cross-release feature entirely by Ingo

2017-12-28 Thread Byungchul Park
On Wed, Dec 13, 2017 at 03:24:29PM +0900, Byungchul Park wrote: > Lockdep works, based on the following: > >(1) Classifying locks properly >(2) Checking relationship between the classes > > If (1) is not good or (2) is not good, then we > might get false positives. > > For (1), we don't

[for-416 PATCH v2] bcache: writeback: collapse contiguous IO better

2017-12-28 Thread Michael Lyle
Previously, there was some logic that attempted to immediately issue writeback of backing-contiguous blocks when the writeback rate was fast. The previous logic did not have any limits on the aggregate size it would issue, nor the number of keys it would combine at once. It would also discard

Re: [PATCH IMPROVEMENT] block, bfq: limit sectors served with interactive weight raising

2017-12-28 Thread Holger Hoffstätte
On 12/28/17 12:19, Paolo Valente wrote: (snip half a tech report ;) So either this or the previous patch ("limit tags for writes and async I/O" can lead to a hard, unrecoverable hang with heavy writes. Since I couldn't log into the affected system anymore I couldn't get any stack traces, blk-mq

[PATCH v2] lightnvm: pblk: clear flush point on completed writes

2017-12-28 Thread Hans Holmberg
Move completion of syncs and clearing of flush points to the write completion path - this ensures that the data has been comitted to the media before completing bios containing syncs. Signed-off-by: Hans Holmberg Signed-off-by: Javier González

[PATCH IMPROVEMENT] block, bfq: limit sectors served with interactive weight raising

2017-12-28 Thread Paolo Valente
To maximise responsiveness, BFQ raises the weight, and performs device idling, for bfq_queues associated with processes deemed as interactive. In particular, weight raising has a maximum duration, equal to the time needed to start a large application. If a weight-raised process goes on doing I/O

Re: [RFC] distinguish foreground and background IOs in block throttle

2017-12-28 Thread Paolo Valente
> Il giorno 28 dic 2017, alle ore 02:51, Joseph Qi ha > scritto: > > Hi Paolo, > > On 17/12/27 20:36, Paolo Valente wrote: >> >> >>> Il giorno 25 dic 2017, alle ore 03:44, xuejiufei ha >>> scritto: >>> >>> Hi all, >>> >>> Cgroup writeback is