inaddy@ocfs2defrag:~$ sudo cat /proc/1452/stack [<0>] 0x0 inaddy@ocfs2defrag:~$ while true; do sudo cat /proc/1452/stack; done > bleh.txt inaddy@ocfs2defrag:~$ cat bleh.txt | sort -u [<0>] 0x0 Stack does not help me at all (not being updated in execution path from the user<-> kernel context switch). Still, process is consuming100% of user time: %Cpu3 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1452 root 20 0 1936 428 360 R 100.0 0.0 6:27.67 defragfs.ocfs2 Initial check on time spend scheduling to discard kernel issue like I suspected before: inaddy@ocfs2defrag:~$ sudo perf sched timehist -p 1452 time cpu task name wait time sch delay run time [tid/pid] (msec) (msec) (msec) --------------- ------ ------------------------------ --------- --------- --------- 111.555973 [0003] defragfs.ocfs2[1452] 0.000 0.000 0.000 112.123934 [0003] defragfs.ocfs2[1452] 0.029 0.000 567.930 113.571854 [0003] defragfs.ocfs2[1452] 0.018 0.000 1447.901 115.139790 [0003] defragfs.ocfs2[1452] 0.027 0.000 1567.908 115.555743 [0003] defragfs.ocfs2[1452] 0.030 0.000 415.921 116.123707 [0003] defragfs.ocfs2[1452] 0.027 0.000 567.936 116.867670 [0003] defragfs.ocfs2[1452] 0.019 0.000 743.943 117.571630 [0003] defragfs.ocfs2[1452] 0.025 0.000 703.934 118.243597 [0003] defragfs.ocfs2[1452] 0.026 0.000 671.940 118.443583 [0003] defragfs.ocfs2[1452] 0.028 0.000 199.957 119.587530 [0003] defragfs.ocfs2[1452] 0.017 0.000 1143.929 120.123500 [0003] defragfs.ocfs2[1452] 0.023 0.000 535.945 121.571458 [0003] defragfs.ocfs2[1452] 0.016 0.000 1447.941 123.587358 [0003] defragfs.ocfs2[1452] 0.027 0.000 2015.871 124.123365 [0003] defragfs.ocfs2[1452] 0.036 0.000 535.970 125.123284 [0003] defragfs.ocfs2[1452] 0.020 0.000 999.899 125.603259 [0003] defragfs.ocfs2[1452] 0.032 0.000 479.942 126.883212 [0003] defragfs.ocfs2[1452] 0.029 0.000 1279.924 127.587179 [0003] defragfs.ocfs2[1452] 0.028 0.000 703.938 128.123153 [0003] defragfs.ocfs2[1452] 0.027 0.000 535.946 It spends almost no time in waiting for CPU AND absolutely no time in scheduling (as its the only task currently really running), so its something in userland indeed.... debugging it: (gdb) #0 0x0000ffffbf618b10 in _getopt_internal_r (argc=3, argv=0xfffffffff868, optstring=0xaaaaaaaacfc0 "gvclh", longopts=0x0, longind=0x0, long_only=0, d=d@entry=0xffffbf6cad88 , posixly_correct=) at getopt.c:508 #1 0x0000ffffbf618f0c in _getopt_internal (argc=, argv=, optstring=, longopts=, longind=, long_only=, posixly_correct=) at getopt.c:711 #2 0x0000aaaaaaaab43c in parse_opt (_mode_flag=, argv=0xfffffffff868, argc=3) at main.c:585 #3 main (argc=3, argv=0xfffffffff868) at main.c:653 after some time: (gdb) bt #0 0x0000ffffbf618950 in _getopt_internal_r (argc=3, argv=0xfffffffff868, optstring=0xaaaaaaaacfc0 "gvclh", longopts=0x0, longind=0x0, long_only=0, d=d@entry=0xffffbf6cad88 , posixly_correct=) at getopt.c:500 #1 0x0000ffffbf618f0c in _getopt_internal (argc=, argv=, optstring=, longopts=, longind=, long_only=, posixly_correct=) at getopt.c:711 #2 0x0000aaaaaaaab43c in parse_opt (_mode_flag=, argv=0xfffffffff868, argc=3) at main.c:585 #3 main (argc=3, argv=0xfffffffff868) at main.c:653 after some more time: (gdb) bt #0 0x0000ffffbf618cec in _getopt_internal_r (argc=3, argv=0xfffffffff868, optstring=0xaaaaaaaacfc0 "gvclh", longopts=0x0, longind=0x0, long_only=0, d=d@entry=0xffffbf6cad88 , posixly_correct=) at getopt.c:512 #1 0x0000ffffbf618f0c in _getopt_internal (argc=, argv=, optstring=, longopts=, longind=, long_only=, posixly_correct=) at getopt.c:711 #2 0x0000aaaaaaaab43c in parse_opt (_mode_flag=, argv=0xfffffffff868, argc=3) at main.c:585 #3 main (argc=3, argv=0xfffffffff868) at main.c:653 Checking glibc getopt.c code (around lines 500 <-> 512) I can see we are stuck in this loop: if (d->__nextchar == NULL || *d->__nextchar == '\0') { /* Advance to the next ARGV-element. */ ... } And I'll try to discover why tomorrow (and report upstream).