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]

Re: Changing log()


hunt wrote:

> [...]
> Actually I was planning on tackling s similar issue soon. It is part of
> a proposal to create "temporary buffers".  [...]
> 
> < create a buffer named tmp1 of size M>

How would this buffer creation work in practice?  Remember to what
effort we go now to avoid any run-time memory allocation.

> buffer(tmp1) ; # all prints go to tmp1 now

Would this effect the current probe only?  If not, what about
concurrency issues?

> < print a bunch of stuff> 

(presumably, using plain printf() or similar functions?

> buffer (stdout) ; # switch back to standard buffer
> buffer_write (tmp1) ; # copy tmp1 to stdout

What if the "tmp1" buffer is larger than the available output space? 


> I see these as a way to buffer lots of output without writing huge
> log files. They would be circular and extremely fast because they
> don't have userspace transport, disk IO, etc.

You realize that there is an inherent tension between being "huge" and
"extremely fast"?  Allocation of big buffers won't be fast, nor
necessarily successful.  Saving them to the standard output streams
(user-space via procfs or whatever) will be limited too, in terms of
throughput and possibly another level of buffering.

Some more quantitative analysis would be nice to see to justify this
approach, such as a worked-out example with estimated probing
rate/counts and enqueued trace data amounts.


- FChE


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