Re: Merging relayfs?

From: Tomasz Kłoczko (kloczek_at_rudy.mif.pg.gda.pl)
Date: 07/13/05

  • Next message: Bill Davidsen: "Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt" 
    Date:	Wed, 13 Jul 2005 18:22:27 +0200 (CEST)
To: Vara Prasad <prasadav@us.ibm.com>

    On Wed, 13 Jul 2005, Vara Prasad wrote:
    [..]
    > O.K, looks like you are agreeing that we need a buffering mechanism in the
    > kernel to implement speculative tracing, right.

    Each agregator have own data. This data are buffered ..
    In this sense: yes, it infrastructure for allocate, deallocate, copy ..
    (generaly) operate on this buffers is needed.

    > 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?

    Sorry but not. Relayfs this is much more than it is required for simple
    manage buffers (better will be say in this point "probes data
    containers"). All this kind operation can be performed
    using reference/index.

    > 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?

    Correct me if I'm wrong .. ant try fill all this area where you see my
    worse knowledge then yours or other strict kernel developers.

    1) relayfs was prepared for low latency on move data outside kernel space,
    2) getting data from probes do not require organize all them in regular
        file system structure also in most cases will do not require low latency.
        Only in all cases where buffer must be neccessarly moved outside kernel
        space will require minimal overhead.

    Many other kernel sugbsystem allow transfer data as result of simple
    request with argument as reference/index. Organize all data stored/used by
    probes in named structure (if it is *realy* neccesary) can be IMO moved
    outside kernel space.
    Why ? becase *all operations on kernel side on this data* seems can be
    performed without addidional namig abstraction (buffer number, buffer size
    and data type stored in buffer it will be all what is neccessary in
    probably all cases even in case operate on complex data).

    If you realy want get data from probes via fopen()/read() why not map
    "probes data containers" to procfs/sysfs ? For reciving signals from
    perobes for move out of kernel space mapped buffer content and/or ALSO
    reciving signals with DATA (on request from user space) probably can be
    performed via existing netlink infrastrucrure or (higher) event
    notification.

    (?)

    Allow me ask you: do you try test is using netlink will allow perform
    operations in neccessary time frame ? (with additional assumption agregate
    maximum data possibly in "short range" from probe) .. probably not because
    most of skeleton ussages of KProbes and also LTT interface was prepared
    with assumption agregate data outside kernel space.
    Do you see this ?

    This was and sill is core cause of LTT problems and why it will never will
    be so usefull as DTrace. Agregate data in possible "short distance" from
    probe is *core DTrace assumption*. Simple .. this why using DTrace is
    *very light* even if you are enable/hang thousands of probes inside kernel
    space and still it allwo use this kind of technik evel in very fragile
    (from point of view stabilyty) or under very high presure systems.

    kloczek 

    -- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
-
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/
  • Next message: Bill Davidsen: "Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt"

    Relevant Pages

    • [PATCH] Documentation update for relay interface
      ... Here's updated documentation for the relay interface, ... +efficiently log and transfer large quantities of data from the kernel ... +A 'relay channel' is a kernel->user data relay mechanism implemented ... +buffer data. ...
      (Linux-Kernel)
    • [RFC] Userspace tracing memory mappings
      ... 16 per cpu trace buffers at the same time. ... - Also need some space for the kernel to export control information. ... When the process issues its first buffer switch (that's a second added ...
      (Linux-Kernel)
    • Re: Question about memory mapping mechanism
      ... The thing is that I'd like to prevent kernel to swap these pages out, ... the buffer pages, I should increase the referrence of the pages by calling ... Well it wasn't this code in particular, but another driver I was putting ... use the infiniband approach to mmap() the user-space pages and send them ...
      (Linux-Kernel)
    • Re: contigmalloc() and mmap()
      ... there seems no big differences between the kernel ... > to the card on another node, it will be DMAed to memory too. ... The buffer is mmaped to user process space, ... > mmap driver's buffer (allocated by contigmalloc()) and is killed, ...
      (freebsd-hackers)
    • Re: How to use make a UMA frame buffer mapping from kernel to user
      ... How can I make sure it's in the right context of that user-mode process? ... allocate buffer in kernel space and map it to user space. ... Why we use reserved virtual space (created by MmAllocateMappingAddress ... allocate the buffer in user-mode, and lock it in the kernel driver. ...
      (microsoft.public.development.device.drivers)