Tomasz Kłoczko wrote:
On Tue, 12 Jul 2005, Vara Prasad wrote:
Tomasz Kłoczko wrote:
On Tue, 12 Jul 2005, Tom Zanussi wrote:
=?ISO-8859-2?Q?Tomasz_K=B3oczko?= writes:
> On Tue, 12 Jul 2005, Tom Zanussi wrote:
[...]
>
> OK .. "so you can say better is stop flushing buffers on measure
which
> wil take day or more" ? :_)
> Some DTrace probes/technik are specialy prepared for long or evel
very
> long time experiment wich will only prodyce few lines results on
end of
> experiment.
> Look at DTrace documentation for speculative tracing:
> http://docs.sun.com/app/docs/doc/817-6223/6mlkidli7?a=view
How do you propose to implement speculative tracing without a buffer
to hold the data, when data needs to stay in the kernel for a while
before we decide to commit or discard?
Buffering some data inside kernel space and buffering with
infrastructure for transfer to user space this are two diffrent things.
kloczek
O.K, looks like you are agreeing that we need a buffering mechanism in
the kernel to implement speculative tracing, right. Once we have the
buffering mechanism we need to create an efficient API for producers of
the data to write to that buffering scheme. To my knowledge there is no
such generic buffering mechanism already in the kernel, Relayfs
implements that buffering scheme and an efficient API to write to it.
Isn't that a good reason to have Relayfs merged?
Once the data in the buffer is decided to be committed you need a
mechanism to get that data from the kernel to userspace. If you don't
like Relayfs transfer mechanism, what do you suggest using?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
