"Perez-Gonzalez, Inaky" wrote:
> But you don't need to provide buffers, because normally the data
> is already in the kernel, so why need to copy it to another buffer
> for delivery?
There is no copying going on. As with kue, you have to have a
packaged structure somewhere to send to the recipient. As per
your code:
+ _m4 = kmalloc (sizeof (*_m4), GFP_KERNEL);
+ memcpy (_m4, &m4, sizeof (m4));
+ _m4->kue.flags = KUE_KFREE;
+ kue_send_event (&_m4->kue);
_m4 and m4 are placeholders that must exist before being queued,
there's just no way around that. With relayfs you would do:
relay_write(channel_id, &m4, , time_delta_offset);
When the channel buffer is mmap'ed in the user-process' address space,
all that is needed is a write() with a pointer to the buffer for it
to go to storage. There is zero-copying going on here.
Plus, kue uses lists with next & prev pointers. That simply won't
scale if you have a buffer filling at the rate of 10,000 events/s.
Also, at that rate, you simply can't wait on the reader to read
events one-by-one until you can reuse the structure where you
stored the data to be read. The data has to be secured in the buffer
at the return of the logging function (relay_write() in the case of
relayfs) and the reader has to read events by the thousand every
time.
> This is where I think relayfs is doing too much, and that is the
> reason why I implemented the kue stuff. It is very lightweight
> and does almost the same [of course, it is not bidirectional, but
> still nobody asked for that].
relayfs is there to solve the data transfer problems for the most
demanding of applications. Sending a few messages here and there
isn't really a problem. Sending messages/events/what-you-want-to-call-it
by the thousand every second, while using as little locking as possible
(lockless-logging is implemented in the case of relayfs' buffer handling
routines), and providing per-cpu buffering requires a different beast.
Karim
===================================================
Karim Yaghmour
karim@opersys.com
Embedded and Real-Time Linux Expert
===================================================
-
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/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:22 EST