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
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
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
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
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
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
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
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
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
> 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
10 matches
Mail list logo