Comment 31 for bug 1328727

Created attachment 135171
session.log.s2disk.20140505_2238.bz2

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 <email address hidden> 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