September 2017 - kernelnewbies@kernelnewbies.org

Swap causing huge latency on disk IO operations
by Sudharsan Vijayaraghavan Sept. 10, 2017

Sept. 10, 2017

Hi All, We are running a pretty (rather a very old kernel) 2.6.32. Nevertheless we do see huge latency on disk IO once system starts using swap. Tweaking of various swap related variables under /proc/sys/vm did not make a big difference. The idea is we are having big memory requirement, hence using swap is expected. Unexpected thing is that this is causing very high latency. The precise latency happens as follows swap_readpage () invokes lock_page() and then the process(thread) of interest gets scheduled out through io_schedule(), it does not run again for several seconds. This occurs due to the fact another thread is writing to disk using ext3 functions, wherein it took lock_page() and spends lot of time to write data to disk before finally invoking unlock_page(). top shows huge iowaits (nr_iowait). Is it expected design behavior that Linux performs bad with swap particularly for disk operations? Tweaking elevator algorithm, io size, block size also did not help. Now we are changing ext3 mounts from data=ordered to data=writeback to see if it helps to reduce disk latency when we run into swap usage. We use RAID along with LVM. We are also experimenting by removing LVM to see if improves the behaviour. Any inputs will be immense help Thanks, Sudharsan

3 5

Numa node 0 is missing from /sys/devices/system/node , only Numa node 1 is shown
by Kevin Wilson Sept. 7, 2017

Sept. 7, 2017

Hi, I have Ubuntu 14.04.5 LTS on x86_64 machine. I am using the kernel as shipped with the distro, no modification whatsoever. After fresh reboot I do see Numa node 1 but there is no Numa node 0 under: /sys/devices/system/node What can be the reason for this ? lscpu shows two sockets but only one NUMA node: lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 16 On-line CPU(s) list: 0-15 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 2 NUMA node(s): 1 ... and cat /boot/config-4.4.0-31-generic | grep CONFIG_NUMA shows: CONFIG_NUMA_BALANCING=y CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y CONFIG_NUMA=y # CONFIG_NUMA_EMU is not set Also dmesg | grep -i numa [ 0.000000] NUMA: Initialized distance table, cnt=2 [ 0.000000] NUMA: Node 1 [mem 0x00000000-0xbfffffff] + [mem 0x100000000-0x33fffffff] -> [mem 0x00000000-0x33fffffff] Any ideas ? Regards, Kevin

2 1

driver_probe_device never called for nested device
by Mathieu Malaterre Sept. 7, 2017

Sept. 7, 2017

Hi all, I am trying to understand the mechanism for driver_probe_device for my specific setup. It seems that I cannot bind the driver to the device in the following case (nested node): cgu: jz4780-cgu@10000000 { compatible = "ingenic,jz4780-cgu", "syscon"; (...) rng: rng@d8 { compatible = "ingenic,jz4780-rng"; }; }; Using CONFIG_DEBUG_DRIVER=y, all I can see in the log is: Sep 6 22:06:36 ci20 kernel: [ 0.180304] bus: 'platform': add driver jz4780-rng While I would have expected something like: Sep 6 22:30:57 ci20 kernel: [ 0.167017] bus: 'platform': add driver jz4780-rng Sep 6 22:30:57 ci20 kernel: [ 0.167033] bus: 'platform': driver_probe_device: matched device 100000d8.rng with driver jz4780-rng Sep 6 22:30:57 ci20 kernel: [ 0.167038] bus: 'platform': really_probe: probing driver jz4780-rng with device 100000d8.rng Did I miss something from the documentation about nested node ? I failed to understand the code in drivers/base/bus.c & drivers/base/dd.c to understand how the device tree is traversed (for instance: which bus is not considered). For reference: * https://github.com/torvalds/linux/blob/master/arch/mips/boot/dts/ingenic/jz… * https://github.com/torvalds/linux/blob/master/drivers/clk/ingenic/jz4780-cg… Thanks for help, -- Mathieu

1 0

USB keyboard can NOT wakeup from S3( suspend to RAM )
by jingyun＠cpu-os.ac.cn Sept. 5, 2017

Sept. 5, 2017

hi, there thx in advance; I encounter a strange (maybe) bug: During the suspending of my linux box(which runs debian 9), I hit the key of the USB interfaced keyboard; after making sure the box enter suspend state for a while ( which I can tell from the power LED blinks), I can NOT wakeup it by hit that keyboard any more. But if I do NOT hit the key during the suspending, I CAN wake it up by hitting the keyboard. After that I tried Ubuntu 16.04(runs 4.4 version kernel ) and Ubuntu 14.04 ( 3.13 kernel). And I found all of them got the same problem; Do not know if this is the right place to ask. Just a try. Thanks again. Jim

5 9