Bug #58
closedsched_getcpu triggers a system call on glibc older than 2.14
0%
Description
tracing "hello" with kernel tracing enabled lets us discover that sched_getcpu, supposed to be a vDSO, actually triggers a system call:
[16:05:32.991027867] (+0.000000909) ust_tests_hello:tptest: { 1 }, { intfield = 9, intfield2 = 0x9, longfield = 9, netintfield = 9, netintfieldhex = 0x9, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4, seqfield2 = "test", stringfield = "test", floatfield = 2222, doublefield = 2 }
[16:05:32.991029728] (+0.000001861) sys_getcpu: { 1 }, { cpup = 0x7FFF1B010350, nodep = 0x0, tcache = 0x7FC76A03E7D8 }
[16:05:32.991033220] (+0.000003492) exit_syscall: { 1 }, { ret = 0 }
[16:05:32.991034256] (+0.000001036) ust_tests_hello:tptest: { 1 }, { intfield = 10, intfield2 = 0xA, longfield = 10, netintfield = 10, netintfieldhex = 0xA, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4, seqfield2 = "test", stringfield = "test", floatfield = 2222, doublefield = 2 }
[16:05:32.991036204] (+0.000001948) sys_getcpu: { 1 }, { cpup = 0x7FFF1B010350, nodep = 0x0, tcache = 0x7FC76A03E7D8 }
[16:05:32.991036936] (+0.000000732) exit_syscall: { 1 }, { ret = 0 }
It will need to be investigated at the glibc and kernel level, and maybe we will have to implement our own wrapper over the vDSO.
Updated by Mathieu Desnoyers almost 13 years ago
16:31 < derRichard> Compudj: maybe your glibc is too old
16:31 < derRichard> AFAIK sched_getcpu() is using the vdso since 2.14
16:33 < Compudj> oh, and debian unstable are still at 2.13 for some reason
Updated by Yannick Brosseau over 12 years ago
- Subject changed from sched_getcpu triggers a system call to sched_getcpu triggers a system call on glibc older than 2.14
Updated by Mathieu Desnoyers over 12 years ago
- Status changed from New to Won't fix
This is a known glibc limitation, not UST's fault. This works fine with newer glibc versions. The solution is to upgrade glibc.