RE: Making the transport layer more robust

[Mark Wielaard <mjw at redhat dot com>]

Hi Turgis,

On Thu, 2011-08-25 at 14:12 +0200, Turgis, Frederic wrote:

> => long polling delay works OK, kernel periodic check for IO seems
> redundant with userspace but kernel polling for exit is needed

The kernel side "polling" is not just for exit, it is for any cmd
message that is generated from a possible "unsafe" context. We might
want to investigate whether we can be a little smarter about this (maybe
use inatomic() as a check whether we may announce immediately or need
the timer, and/or make the timer smarter so it fires less frequently
when we don't expect any messages?).

> - after changes:
> * userspace: we use "pselect" if supported. Great !
> * kernel space:
>    + polling for exit is still needed
>    + polling for IO:
>       * for cmd messages that don't announce themselves -> now
> mandatory otherwise pselect() would not return
>       * for other cmd messages, it still does not look needed but
> there is no added value in differentiating them from above messages as
> we must do polling
> 
> => we will experiment with this version playing only with the delay
> between 2 pollings (STP_CTL_TIMER_INTERVAL)

I am very interested in any results you get from the new code.

Note that there is another timer firing periodically for "normal"
transport messages (none-command/warn/err/exit/system). This is
controlled by STP_RELAY_TIMER_INTERVAL. This is needed because relayfs
can only notify user space on "buffer overflow". So when running stap in
"line mode" (aka non-bulk-mode, not using stap -b), the kernel-side
needs to periodically poll to see if any new messages should be
immediately given to user space. Running in bulk-mode (-b) will
completely get rid of this timer, but I don't yet know how to make it
less noticeable for line-mode, when you want to get notified about probe
messages immediately.

Please let us know about any experiments you run that might help us
better tune these timers.

Thanks,

Mark