FS#38800 - [linux] 3.12: desktop feezes with nfs write and activated swap space
Attached to Project:
Arch Linux
Opened by Michael (hede) - Wednesday, 05 February 2014, 15:16 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 14 October 2017, 14:23 GMT
Opened by Michael (hede) - Wednesday, 05 February 2014, 15:16 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 14 October 2017, 14:23 GMT
|
Details
Description:
If I copy a big file via nfs to some server, my Desktop is freezing every other second. Mouse lags, etc. Wired thing: If I disable swap space, everything turns to normal. Additional info: IBM Thinkcentre A60 NVidia NForce 410 / MCP51 / Geforce 6050 Broadcom Corporation NetXtreme BCM5788 1 GB Ram, Sata Disk Linux 3.12.9-1-ARCH i686 Nouveau GPU driver Steps to reproduce: prerequisite: some Network Server exporting an NFS share with async option set (here it's a dm600 Dreambox) At the arch desktop client: # mount 192.168.2.49:/media/hdd -o nfsvers=3,async,rsize=8192,wsize=8192 /mnt/tmp2 # cp /home/user/somebigfile /mnt/tmp2/ result: desktop is freezing, mouse lags, ... # swapoff -a result: everything turns to normal, file copy is progressing. # swapon -a result: desktop is freezing, mouse lags, slow copy progress, ... |
This task depends upon
Closed by Doug Newgard (Scimmia)
Saturday, 14 October 2017, 14:23 GMT
Reason for closing: No response
Saturday, 14 October 2017, 14:23 GMT
Reason for closing: No response
If swapspace is activated and the desktop is laggy, I can kill the copy command ([ctrl]-[c] in the xterm), then immediatly everything is fine (no lags) even while the buffers are still flushing (command prompt not appearing) and network traffic is still on-going!
total used free shared buffers cached
Mem: 996480 944308 52172 26684 1444 217712
-/+ buffers/cache: 725152 271328
Swap: 974844 0 974844
... so it's not swap activity which is causing the lags.
Lags starting 30-60 seconds after I start "cp" to the nfs share. If it's lagging and I do a "swapoff -a", then it needs 10-20 seconds to settle down, then the lags mitigate/soften. (remember: that's the case even if swap space is nearly unused, in my last Test there was 356kB swap space usage at the time when I did the "swapoff -a")
btw: the nfs server here is some dreambox set top box, which limits the network traffic to 1-3 MB/s, so at the pc side (arch) there shouldn't be anything that busy ...
The problem still exist with:
Linux pcname 3.13.2-1-ARCH #1 SMP PREEMPT Thu Feb 6 23:34:40 CET 2014 i686 GNU/Linux
Interrupt table:
$ cat /proc/interrupts
CPU0 CPU1
0: 52 0 XT-PIC-XT-PIC timer
6: 0 3 IO-APIC-edge floppy
7: 1 0 IO-APIC-edge
8: 0 1 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
11: 1185 1034539 IO-APIC-fasteoi enp3s8
14: 10 1962 IO-APIC-edge pata_amd
15: 0 0 IO-APIC-edge pata_amd
19: 2 986 IO-APIC-fasteoi snd_hda_intel
20: 0 0 IO-APIC-fasteoi sata_nv
21: 179 32062 IO-APIC-fasteoi sata_nv
22: 0 4 IO-APIC-fasteoi ehci_hcd:usb1
23: 183 31840 IO-APIC-fasteoi ohci_hcd:usb2
41: 1 804 PCI-MSI-edge nouveau
NMI: 9 11 Non-maskable interrupts
LOC: 149844 139431 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 9 11 Performance monitoring interrupts
IWI: 8484 7320 IRQ work interrupts
RTR: 0 0 APIC ICR read retries
RES: 216842 170744 Rescheduling interrupts
CAL: 83 2178 Function call interrupts
TLB: 1641 3014 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 7 7 Machine check polls
ERR: 1
MIS: 0
Btw, I remember I've seen some error message regarding linux detecting some mainboard bug where some timer is not connected to the apic here. I cannot find it in dmesg now. Will check that later.
[ 0.026666] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
But this seems not to be the issue because:
[ 0.033333] ...trying to set up timer as ExtINT IRQ...
[ 0.067041] ..... works.
And timer interrupts are comming in:
0: 52 0 XT-PIC-XT-PIC timer
It's still reproducible.
The PC has 4GB Ram now. Behaviour is different. GUI is clean, but surfing with firefox, opening some tabs, it stalls every now and then.
Using mem=1G (kernel cmdline) and opening some applications I can reproduce the old behaviour in lagging/stuttering GUI incl. Mouse movement.
But this seems only affecting X. Opening xterm and press and holding a key results in lagging/stuttering char input. Switching to a VT (i.e. [ctrl]-[alt]-[F2]) and press and holding a key results in clean/consistent/regular input.
Additional info: Besides 3 more GB RAM the PC has a Radeon HD 5770 now, using the included open source radeon driver.