Re: [PATCH] x86_64: fix delayed signals

Linus Torvalds
2008-07-11T18:32:22Z

On Fri, 11 Jul 2008, Linus Torvalds wrote:
>
> Btw, did any of the impacted people test -rc9? Edwin's report is about
> -rc2 and -rc8, and one of the things we fixed since -rc8 is that incorrect
> and unintentional nr_zones zeroing that effectively disabled kswapd - and
> made everybody do synchronous memory freeing when they wanted to allocate
> more memory.. That can play havoc with any interactive stuff.

Hmm. Edwin's latencytop output includes this (ignoring the _very_ top
entries that are all either CD-ROM media change tests or are interruptible
pipe/select things) at the top:

21 10264428 915514 get_request_wait __make_request generic_make_request
submit_bio xfs_submit_ioend_bio xfs_submit_ioend
xfs_page_state_convert xfs_vm_writepage __writepage
write_cache_pages generic_writepages xfs_vm_writepages

26 3369263 2260529 down xfs_buf_iowait xfs_buf_iostart xfs_buf_read_flags
xfs_trans_read_buf xfs_imap_to_bp xfs_itobp xfs_iread
xfs_iget_core xfs_iget xfs_lookup xfs_vn_lookup 1 17888 17888 down
xfs_buf_iowait xfs_buf_iostart xfs_buf_read_flags
xfs_trans_read_buf xfs_da_do_buf xfs_da_read_buf
xfs_dir2_block_getdents xfs_readdir xfs_file_readdir vfs_readdir
sys_getdents64
..

which says that (a) yes, readdir() is part of the problematic paths, so my
patch may make a difference but also (b) we also have so many writeback
IO's in flight that the write request queue is totally full, and the
writing side is simply waiting for the queue to empty.

I guess (b) isn't a surprise (considering the load), but it does explain
why any IO read will be very much delayed. If the IO scheduler (or the
disk itself - tagged commands etc) doesn't prioritize reads and
effectively always put them ahead of the queue, you can get very very long
latencies just because you have to wait for lots of writes to complete
first.

Linus