lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 5 Feb 2010 14:00:02 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Jan Engelhardt <jengelh@...ozas.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kswapd continuously active

On Fri, Feb 05 2010, Jan Engelhardt wrote:
> 
> On Monday 2010-01-25 14:22, Jan Engelhardt wrote:
> >On Monday 2010-01-25 14:06, Jens Axboe wrote:
> >>> 
> >>> with 2.6.32.2 on sparc64 I am seeing that there is a sync(1) process 
> >>> busy in D state, with the following trace:
> >>> 
> >>> sync          D 000000000079299c  7552  4851      1 0x208061101000004
> >>> Call Trace:
> >>>  [000000000053ca58] bdi_sched_wait+0xc/0x1c[...]
> >>>  [000000000053ca78] sync_inodes_sb+0x10/0xfc
> >>> 
> >>> kswapd is also active all the time, writing something to disk[...]
> >>
> >>That doesn't sound good. What does /proc/meminfo say? What file systems
> >>are you using?
> 
> >January 25			Feb-05
> >MemTotal:        8166752 kB	8166752
> >MemFree:         3243552 kB	3781776
> >Buffers:          207968 kB	4912
> >Cached:          2728216 kB	2684400
> >SwapCached:            0 kB	0
> >Active:          2203136 kB	495624
> >Inactive:        2152544 kB	3263136
> >Active(anon):    1167256 kB	488168
> >Inactive(anon):   252952 kB	583912
> >Active(file):    1035880 kB	7456
> >Inactive(file):  1899592 kB	2679224
> >Unevictable:           0 kB	0
> >Mlocked:               0 kB	0
> >SwapTotal:             0 kB	0
> >SwapFree:              0 kB	0
> >Dirty:            141624 kB	2662184
> >Writeback:             0 kB	..
> 
> Today this happened again. So I looked at /proc/meminfo to paste today's
> values next to those from January. That is when I noticed the "Dirty"
> value - and thus I ran
> 
> 	watch -d -n 1 'grep Dirty /proc/meminfo'
> 
> What I see is that the dirty amount - a sync is currently running -
> only decreases with at most 400 KB/sec, often less than that.

I'm guessing the barriers and commits are what is killing your
performance. What happens with barrier=0?

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ