> About the second one: > > > ==The Second Issue (aka "The Busy Looping sync()" case) == > > The box is different from first, so conditions are a bit different. > > - /dev/root on / type btrfs (rw,noatime,autodefrag) > > (note autodefrag!) > > - 15% full 594GB filesystem (usual nonmixed mode) > > > > $ liferea > > > > $ sync > > Got CPU is 100% loaded > > Still reproducible with 2 patches above + $SUBJ one. strace says it hangs in > strace() syscall. Stack trace is odd: > # cat /proc/`pidof sync`/stack > [] 0xffffffffffffffff "got" stack of the looper with such hack: $ while :; do sudo echo "-"; cat /proc/2304/stack | fgrep -v '[] 0xffffffffffffffff'; done | uniq [] find_get_pages_tag+0x14d/0x1a0 [] __lock_acquire+0x5a1/0xbd0 [] filemap_fdatawait_range+0x9d/0x1b0 [] filemap_fdatawait+0x22/0x30 [] sync_inodes_sb+0x1c4/0x250 [] __sync_filesystem+0x78/0x80 [] sync_one_sb+0x17/0x20 [] iterate_supers+0x7e/0xe0 [] sys_sync+0x40/0x60 [] system_call_fastpath+0x16/0x1b - [] sync_inodes_sb+0x1b1/0x250 [] __sync_filesystem+0x78/0x80 [] sync_one_sb+0x17/0x20 [] iterate_supers+0x7e/0xe0 [] sys_sync+0x40/0x60 [] system_call_fastpath+0x16/0x1b - [] sync_inodes_sb+0x1b1/0x250 [] __sync_filesystem+0x78/0x80 [] sync_one_sb+0x17/0x20 [] iterate_supers+0x7e/0xe0 [] sys_sync+0x40/0x60 [] system_call_fastpath+0x16/0x1b - [] retint_kernel+0x26/0x30 [] find_get_pages_tag+0x148/0x1a0 [] pagevec_lookup_tag+0x20/0x30 [] filemap_fdatawait_range+0x9d/0x1b0 [] filemap_fdatawait+0x22/0x30 [] sync_inodes_sb+0x1c4/0x250 [] __sync_filesystem+0x78/0x80 [] sync_one_sb+0x17/0x20 [] iterate_supers+0x7e/0xe0 [] sys_sync+0x40/0x60 [] system_call_fastpath+0x16/0x1b Looks like dirty inode count (or dirty page count) is affected by the $SUBJ patch. -- Sergei