This is the mail archive of the systemtap@sources.redhat.com 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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |