This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug librt/20950] New: Do asynchronous execution for lio_listio's IOs
- From: "Ulrich.Windl at rz dot uni-regensburg.de" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 08 Dec 2016 16:23:45 +0000
- Subject: [Bug librt/20950] New: Do asynchronous execution for lio_listio's IOs
- Auto-submitted: auto-generated
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.