Hello, 1) Attached a full function-trace log + other SysRq outputs, see [1] attached. I saw bdi_...() calls in the s2disk paths, but didn't check in detail Probably more efficient when one of you guys looks directly. 2) /sys/kernel/debug/bdi/<dev>/stats They are also in [1] - however the major/minors of my sdbX didn't match with the /sys/.../bdi/<dev>'s. So I just displayed them all. 3) What is the estimated bandwith? It's an Samsung SSD 840 PRO, in this system: Read: 237 MB/s, Write 265 MB/s - see [2] (the faster writing is maybe due caching?) Just by curiosity: Can you also reproduce it ? ... since the test is quite simple. Or is it something specific in my system here ? BR, Oliver --- [1] Attached session.log.s2disk.20140505_2238.bz2 - 18MiB uncompressed function-trace output + others - The bdi outputs are also in there [2] Rough bandwidth tests Read: --- gamix64:~# swapon -s Filename Type Size Used Priority /dev/sdb7 partition 4193276 0 -1 gamix64:~# dd if=/dev/sdb7 bs=1024 count=$[1024*1024*4] |pv >/dev/null 4GB 0:00:18 [ 226MB/s] [ <=> ]4193280+0 records in 4193280+0 records out 4293918720 bytes (4.3 GB) copied, 18.1509 s, 237 MB/s --- Write: --- gamix64:~# dd if=/dev/zero bs=1024 count=$[1024*1024*4] |pv >/root/Test/test1.bin 4194304+0 records inMB/s] [ <=> ] 4194304+0 records out 4294967296 bytes (4.3 GB) copied, 16.2039 s, 265 MB/s 4GB 0:00:15 [ 256MB/s] [ <=> ] --- On Mon, 5 May 2014 18:10:53 +0200 Jan Kara <jack@xxxxxxx> wrote: > > Ignoring free pages due to dirty_balance_reserve, inactive+active > > file yields 3481 dirtyable pages, which sets the global limits to > > 174 pages background and 348 pages foreground with the default > > configuration. It's low, but not 0. > OK, so we are over the dirty_limit. > > > So why is the dirtier throttled to starvation when the background > > flusher is not even running? Shouldn't they be looking at the same > > numbers and behave inversely? > These days there isn't a background flusher thread but a workqueue > which handles the flushing work. But still you should see that in a > process list like "flush-$dev". Can you check whether > balance_dirty_pages() properly calls bdi_start_background_writeback() > and whether wb_do_writeback() gets to run (there are tracepoints in > there)? Also can you have a look > in /sys/kernel/debug/bdi/<dev>/stats? What is the estimated bandwith? > > Honza
Attachment:
session.log.s2disk.20140505_2238.bz2
Description: application/bzip