Re: ext4 hang and per-memcg dirty throttling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 12, 2018 at 02:11:30PM +0200, Jan Kara wrote:
> 
> Yes, I guess you're speaking about the one Chris Mason mentioned [1].
> Essentially it's a priority inversion where jbd2 thread gets blocked behind
> writeback done on behalf of a heavily restricted process. It actually is
> not related to dirty throttling or anything like that. And the solution for
> this priority inversion is to use unwritten extents for writeback
> unconditionally as I wrote in that thread. The core of this is implemented
> and hidden behind dioread_nolock mount option but it needs some serious
> polishing work and testing...
> 
> [1] https://marc.info/?l=linux-fsdevel&m=151688776319077

I've actually be considering making dioread_nolock the default when
page_size == block_size.

Arguments in favor:

1)  Improves AIO latency in some circumstances
2)  Improves parallel DIO read performance
3)  Should address the block-cg throttling priority inversion problem

Arguments against:

1)  Hasn't seen much usage outside of Google (where it makes a big
    difference for fast flash workloads; see (1) and (2) above)
2)  Dioread_nolock only works when page_size == block_size; so this
    implies we would be using a different codepath depending on
    the block size.
3)  generic/500 (dm-thin ENOSPC hitter with concurrent discards)
    fails with dioread_nolock, but not in the 4k workload

Liu, can you try out mount -o dioread_nolock and see if this address
your problem, if so, maybe this is the development cycle where we
finally change the default.

						- Ted



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux