linux-kernel - 3.12-rcX - NFS regression - kswapd0 / kswapd1 stays using 100% CPU?

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-next>] [day] [month] [year] [list]

Date:	Thu, 17 Oct 2013 22:42:17 +0200
From:	Helge Deller <deller@....de>
To:	Linux Kernel Development <linux-kernel@...r.kernel.org>,
	NFS list <linux-nfs@...r.kernel.org>,
	list parisc-linux <parisc-linux@...ts.parisc-linux.org>
Subject: 3.12-rcX - NFS regression - kswapd0 / kswapd1 stays using 100% CPU?

I'm seeing a regression with current kernel git head when using NFS-mounts.
Architecture in my case is parisc, although I don't think that this is relevant.
At least kernel 3.10 (and I think 3.11) didn't showed that problem.

The symtom is, that "top" shows high usage of either kswapd0 or kswapd1.
Here is an output with kswapd1:
  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM     TIME+ COMMAND
   37 root      20   0     0    0    0 R  91.8  0.0  63:00.40 kswapd1
28448 root      20   0  3252 1428 1060 R  15.3  0.0   0:00.09 top
    1 root      20   0  2784  988  852 S   0.0  0.0   0:09.95 init

This is what ps shows:
lsXXXX:~# ps -ef |  grep mount
root      1181     1  0 14:51 ?        00:00:18 /usr/sbin/automount --pid-file /var/run/autofs.pid
root     25331  1181  0 21:25 ?        00:00:00 /bin/mount -n -t nfs -s -o nolock,rw,hard,intr homes:/unixhome1 /net/home1
root     25332 25331  0 21:25 ?        00:00:00 /sbin/mount.nfs homes:/unixhome1 /net/home1 -s -n -o rw,nolock,hard,intr

And using sysrq to show the blocked tasks I get in syslog:
SysRq : Show Blocked State
mount.nfs       D 00000000401040c0     0 25332  25331 0x00000010
Backtrace:
[<0000000040113a68>] __schedule+0x500/0x810

I know it's not a problem of the NFS server, since the same mount is still ok on other machines.
The NFS directory was already mounted and in use when this mount happened again (called by cron-job). 
 
Any ideas?

Helge
--
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/