Re: [Bug 75101] New: [bisected] s2disk / hibernate blocks on "Saving 506031 image data pages () ..."

[Oliver Winker <oliverml1@oli1170.net>]

[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]

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@suse.cz> 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 #2: session.log.s2disk.20140505_2238.bz2 --]
[-- Type: application/x-bzip, Size: 652575 bytes --]