Re: more transport questions

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


On Wed, Jul 06, 2005 at 02:55:38PM -0500, Tom Zanussi wrote:
> [...]
>  > on-the-fly impractical?  On the transmission kernel-probe side, would
>  > a relay_flush() after every probe handler be impractical?
>
> Merging on-the-fly would be practical if you flushed every per-cpu
> channel at the same time i.e. forced each per-cpu buffer to finish
> the current sub-buffer so it could be read but that would defeat the
> purpose of using relayfs for high-speed logging.  [...]

OK, I didn't really mean relay_flush but rather stp_print_flush.
Besides, with the presence of a globally unique message serial number,
it would be straightforward to merge on the fly, even if the
processors generate trace messages (apprx == run probe functions) at
very different intervals/rates.


> Martin did create a more efficient sort/merge of the data, but one
> question that came up then was whether the per-cpu data should be
> merged or sorted at all [...]

That's a reasonable question.  In the future, when we get some
experience with such data firehoses, we consider providing more
options.


This reminds me - has anyone made any progress on carrying out some of
the testing outlined by Brad's plan of two months ago?  In particular,
do there now exist kprobes stress tests (numerous / frequent /
densely-packed / long-lived probes)?


- FChE

Attachment: pgp00000.pgp
Description: PGP signature