linux-kernel - Re: kswapd continuously active

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]

Message-ID: <alpine.LSU.2.01.1001251416340.8189@obet.zrqbmnf.qr>
Date:	Mon, 25 Jan 2010 14:22:39 +0100 (CET)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Jens Axboe <jens.axboe@...cle.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kswapd continuously active


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
>>  [000000000079299c] __wait_on_bit+0x58/0xb8
>>  [0000000000792a5c] out_of_line_wait_on_bit+0x60/0x74
>>  [000000000053ca3c] bdi_sync_writeback+0x6c/0x7c
>>  [000000000053ca78] sync_inodes_sb+0x10/0xfc
>>  [0000000000540dd0] __sync_filesystem+0x50/0x88
>>  [0000000000540ec8] sync_filesystems+0xc0/0x124
>>  [0000000000540f80] sys_sync+0x1c/0x48
>>  [0000000000406294] linux_sparc_syscall+0x34/0x44
>> 
>> kswapd is also active all the time, writing something to disk - LED is 
>> blinking, and that's been going on for over half an hour despite the box 
>> being not busy. How do I see what kswapd is still flushing to disk? Even 
>> if all RAM (8 GB) was filled with dirty data, syncing it out would not 
>> take that long - that is to say, the sync process should have long 
>> exited.
>
>That doesn't sound good. What does /proc/meminfo say? What file systems
>are you using?

Eventually that day, the sync finished; not sure what triggered that.
Usually, meminfo looks like when the box is doing something:

14:08 ares:~ > cat /proc/meminfo 
MemTotal:        8166752 kB
MemFree:         3243552 kB
Buffers:          207968 kB
Cached:          2728216 kB
SwapCached:            0 kB
Active:          2203136 kB
Inactive:        2152544 kB
Active(anon):    1167256 kB
Inactive(anon):   252952 kB
Active(file):    1035880 kB
Inactive(file):  1899592 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:            141624 kB
Writeback:             0 kB
AnonPages:       1421448 kB
Mapped:            49904 kB
Shmem:               680 kB
Slab:             429784 kB
SReclaimable:     315760 kB
SUnreclaim:       114024 kB
KernelStack:        9248 kB
PageTables:         6120 kB
Quicklists:        10560 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4083376 kB
Committed_AS:    1626280 kB
VmallocTotal:   1069547520 kB
VmallocUsed:       28816 kB
VmallocChunk:   1069518664 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       4096 kB
14:16 ares:~ > w
 14:17:13 up  6:26,  2 users,  load average: 21.09, 24.41, 22.49

This is used as a compile box, and there are lots of files created
and deleted when there is work - a new chroot for every package
basically, with a total of about 300K such "floating" files.
Filesystem is ext4.

/dev/sda4 / ext4 rw,relatime,barrier=1,data=ordered 0 0

Now that I see barrier=1, maybe I should turn that off in the future
like I did with XFS around 2.6.17[1].

[1] http://lkml.indiana.edu/hypermail/linux/kernel/0605.2/1110.html
--
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/