This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

control channel usermode polling vs runtime "IO check" kernel thread


Hi all,

While using systemtap on a SoC with power management enabled and "tickless" kernel, I have observed regular wake-ups of systemtap/0 kernel thread every scheduler tick. I have related that to below observations/conclusions:

"staprun" main loop indicates "the runtime does not implement select() on the command filehandle so we poll periodically" and there is a 250ms sleep between non blocking reads in mainloop.c

If I understand correctly, a "control channel" read triggers _stp_ctl_read_cmd(xxx) on the runtime side. In case of blocking read, it would block and be unblocked by a _stp_ctl_send(xxx) call or by periodically checking for IO in a kernel thread (_stp_ctl_work_callback() + STP_WORK_TIMER renamed STP_CTL_TIMER_INTERVAL in v1.4).

Of course, as usermode is using polling method, the kernel thread seems useless and I removed it with success (could have increased the timer also).
- Is there something that may be impacted by disabling this kernel thread ?
- are there plans to have a poll() or select() call on usermode side ?


Regards
Fred

PS: data channel also wakes up the platform too much but timers used are more obvious to identify and understand

Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Product System Integration


Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]