IO-less throttling problem statement

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

 



  Hi,

  below is my summary of problems observed with current throttling scheme.
I guess other guys will have some changes but this I what I remembered from
top of my head.

									Honza
---

The problems people see with current balance_dirty_pages() implementation:
a) IO submission from several processes in parallel causes suboptimal IO
patterns in some cases because we interleave several sequential IO streams
which causes more seeks (IO scheduler does not have queue long enough to sort
out everything) and more filesystem fragmentation (currently worked around
in each filesystem separately by writing more than asked for etc.).
b) IO submission from several threads causes increased pressure on shared
data structures and locks. For example inode_bw_list_lock seems to be a
bottleneck on large systems.
c) In cases where there are only a few large files dirty, throttled process
just walks the list of dirty inodes, moves all of them to b_more_io because all
of the inodes have I_SYNC set (other processes are already doing writeback
against these files) and resorts to waiting for some time after which it just
tries again. This creates a possibility for basically locking out a process
in balance_dirty_pages() for arbitrarily long time.

All of the above issues get resolved when IO submission happens from just a
single thread so for the above problems basically any IO-less throttling will
do. We get only a single stream of IO, less contention on shared data
structures from writeback, no problems with not having another inode to write
out.

IO less throttling also offers further possibilities for improvement. If we do
not submit IO from a throttled thread, we have more flexibility in choosing how
often and for how long do we throttle a thread since we are no longer limited
by trying to achieve a sensible IO pattern. This creates a possibility for
achieving lower latencies and smoother wait time behavior. Fengguang is taking
advantage of this in his patch set.
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


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