This is the mail archive of the
mailing list for the systemtap project.
RE: Tune reader_thread poll timeout value
>I agree with Frank that it would be nicer to have one "tunable" instead
Good that you seem OK with introduction of a tunable. I was not sure about correlating s and ns values, I will follow the suggestion of a MS tunable to derive s and ns values.
> Also don't forget to add some small documentation to stap.1
>describing the default value and implications of tuning it higher/lower.
+ comment from Frank Eigler
>Do you notice any adverse effects from this? For an output-heavy script for example, does this cause more out-of-buffer conditions?
- OK for doc. There is a section with MAXNESTING, MAXSTRINGLEN, ... Is it the right place ? It seems it is more related to module itself (like STP_RELAY_TIMER_INTERVAL and STP_CTL_TIMER_INTERVAL that we also use)
- My understanding is that reader_thread ppoll should return (value > 0) on production of a relayfs subbuffer. If timing out, we read an "uncomplete" buffer. So, in case of output-heavy script, we should simply not time-out so tunable should not have any adverse effect.
We keep using 5s tunable and observe (without checking ppoll returned for sub-buffer or timeout):
* not output-heavy script: waiting 5s before having "probe begin" trace ;-) It seems to print something every k*5 s but script is not producing regularly so I will double check with "probe timer.s(2)" + single trace script to observe behaviour
* a bit more output-heavy script (scheduler contextswitch, irqs, workqueues, freq changes): I see stapio waking up between 1 to 3s so I imagine ppoll does not return on timeout but on subbuffer production. Everything goes well. I have 1 colleague who checked when systemtap was breaking due to trace bandwidth, I will make him use 2 versions of staprun.
And then submit final patch to review
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920