[Bug librt/20950] New: Do asynchronous execution for lio_listio's IOs

["Ulrich.Windl at rz dot uni-regensburg.de" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20950

            Bug ID: 20950
           Summary: Do asynchronous execution for lio_listio's IOs
           Product: glibc
           Version: 2.11
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: librt
          Assignee: unassigned at sourceware dot org
          Reporter: Ulrich.Windl at rz dot uni-regensburg.de
  Target Milestone: ---

strace suggests that glibc 2.11.3 on Linux x86_64 (SLES11 SP4) lio_listio()
does read() IOs (LIO_READ) using pread() in one(!) subprocess or thread.
However all IO operations seem to be executed sequentially in the order listed
in aiocb_list[]. When the last operation completed, lio_listio returns (the
subprocess exits).
That's OK for the POSIX semantics, but it's rather useless from a performance
point of view as the operations in aiocb_list[] are expected to be executed as
asynchronous IO. When executing them sequentially, there's no benefit from
using lio_listio().
Please make the elements of aiocb_list[] be asynchronous IOs!

Example strace (10 IOs with 512 bytes block sequential each, reduced to
relevant parts):
[pid  7426] open("/boot/vmlinux-4.4.27-2-default.gz", O_RDONLY) = 3
[pid  7426] fstat(3, {st_mode=S_IFREG|0644, st_size=6864663, ...}) = 0
[pid  7426] brk(0)                      = 0x19cb000
[pid  7426] brk(0x19ed000)              = 0x19ed000
[pid  7426] sched_getparam(7426, { 0 }) = 0
[pid  7426] sched_getscheduler(7426)    = 0 (SCHED_OTHER)
[pid  7426] rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
[pid  7426] mmap(NULL, 28672, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x2b4c48eec000
[pid  7426] mprotect(0x2b4c48eec000, 4096, PROT_NONE) = 0
[pid  7426] clone(Process 7427 attached
 <unfinished ...>
[pid  7427] set_robust_list(0x2b4c48ef29e0, 24 <unfinished ...>
[pid  7426] <... clone resumed> child_stack=0x2b4c48ef1ff0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x2b4c48ef29d0, tls=0x2b4c48ef2700, child_tidptr=0x2b4c48ef29d0)
= 7427
[pid  7427] <... set_robust_list resumed> ) = 0
[pid  7426] rt_sigprocmask(SIG_SETMASK, [],  <unfinished ...>
[pid  7427] pread(3,  <unfinished ...>
[pid  7426] <... rt_sigprocmask resumed> NULL, 8) = 0
[pid  7427] <... pread resumed>
"\37\213\10\10\262\36\35X\2\3vmlinux-4.4.27-2-defau"..., 512, 0) = 512
[pid  7427] getuid()                    = 1000
[pid  7427] rt_sigqueueinfo(7426, SIG_0, {}) = 0
[pid  7427] pread(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512,
512) = 512
[pid  7427] getuid()                    = 1000
[pid  7427] rt_sigqueueinfo(7426, SIG_0, {}) = 0
[pid  7427] pread(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512,
1024) = 512
[pid  7427] getuid()                    = 1000
[pid  7427] rt_sigqueueinfo(7426, SIG_0, {}) = 0
[pid  7427] pread(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512,
1536) = 512
[...]
[pid  7427] getuid()                    = 1000
[pid  7427] rt_sigqueueinfo(7426, SIG_0, {}) = 0
[pid  7427] pread(3,
"G\311\232r\376s\35\263\257\237\273\336\371\205y~\340=Y\326\244\334`\315\223f\324\315\364\200[\27"...,
512, 4608) = 512
[pid  7427] getuid()                    = 1000
[pid  7427] rt_sigqueueinfo(7426, SIG_0, {}) = 0
[pid  7427] futex(0x2b4c492f3284,
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {1481213800, 867373000},
ffffffff <unfinished ...>
[pid  7426] close(3)                    = 0

(actually this doesn't seem to have changed up to glibc-2.22-3)

-- 
You are receiving this mail because:
You are on the CC list for the bug.