[lkml]   [2005]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Merging relayfs?
On Tue, 12 Jul 2005, Baruch Even wrote:
>> Usualy/for now relayfs is used as base infrastructure for variuos
>> debuging/measuring.
>> IMO storing raw data and transfer them to user space it is wrong way.
>> Why ? Becase i adds very big overhead for memory nad storage.
>> Big .. compare to in situ storing partialy analyzed data in conters
>> and other like it is in DTrace.
>> IMO much better will be add base/template set of functions for use in
>> KProbes probes which will come with KProbes code as base tool set. It
>> will allow cut transfered data size from megabites/gigabyutes to hundret
>> bytes/kilo bytes, make debuging/measuring more smooth without additional
>> latency for transfer data outside kernel space.
> There is no relation between using kprobes and reducing the logged data
> size. At the end the debugging/tracing facility is there to provide data
> to the developer who tries to detect the problem or ensure correctness.

Yes, now relayfs and KProbes this two diffrent stories without
strict relation but this relation exist on higher level. Both are used
for solve tha same problems (for measure, watch, some skeleton debug).

Collecting data _without_ dynamically hanged probes requires relayfes but
if collected data can be rolled to data types what you will want to see as
result of experiment (i.e. number of calls of some code asociated with
differnt stack path or number of I/O operation asociated with avarange
transfered data in I/O operations) sucking result data will not be an
issue :)
> The kprobes can only serve as a replacement to changing the source code
> in order to extract the debugging information, and it does it very well.
> Cutting the amount of data transferred is only possible if you add the
> problem detection logic into the kernel and only transport problem
> reports to user-mode.

Of course yes. I want only say: if KProbes will have this logic relayfs
will not be neccessary and instead focusing on develop and merge relayfs
better will be spend time on prepare code for this additional logic
(and probably neccesasary amount of code will be compareable to current
relayfs code size :)

*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
Tomasz Kłoczko, sys adm|*e-mail:*
 \ /
  Last update: 2005-07-12 17:36    [from the cache]
©2003-2011 Jasper Spaans