Trimmed the cc list to those of us still here...
Perez-Gonzalez, Inaky writes:
>
>
> > From: Tom Zanussi [mailto:zanussi@us.ibm.com]
> >
> > In relayfs, the event can be generated directly into the space
> > reserved for it - in fact this is exactly what LTT does. There aren't
> > two separate steps, one 'generating' the event and another copying it
> > to the relayfs buffer, if that's what you mean.
>
> In this case, what happens if the user space, through mmap, copies
> while the message is half-baked (ie, from another CPU) ... won't it
> be inconsistent?
>
There's a count kept, per sub-buffer, that's updated after each write.
If this count doesn't match the expected size of the sub-buffer, the
reader can ignore the incomplete buffer and come back to it later.
The count is maintained automatically by relay_write(); if you're
writing directly into the channel as LTT does though, part of the task
is to call relay_commit() after the write, which updates the count and
maintains consistency.
> > Well, I'm not sure I understand the details of kue all that well, so
> > let me know if I'm missing something, but for kue events to really be
> > self-contained, wouldn't the data need to be copied into the event
> > unless the data structure containing them was guaranteed to exist
> > until the event was disposed of one way or another?
>
> Yes, you have to guarantee the existence of the event data structures
> (the 'struct kue', the embedded 'struct kue_user' and the event data
> itself); if they are embedded into another structure that will dissa-
> pear, you can choose to:
>
> (a) recall the event [if it is recallable or makes sense to do so]
> (b) dynamically allocate the event header and data, generate it
> into that dynamic space.
> (c) dynamically allocate and copy [slow]
>
> (this works now; however, once I finish the destructor code, it
> will give you the flexibility to use other stuff than just kmalloc()).
>
> You can play many tricks here, but that depends on your needs,
> requirements and similar stuff.
>
Well, kmalloc() seems like the most straightforward and convenient way
of managing space for all these individual events, if not the most
efficient. Are you thinking that sub-allocating them out of a larger
buffer might make more sense, for instance? If so, I'd suggest
relayfs for that. ;-) Just kidding, but it does seem you'll have a
certain amount of bookkeeping overhead and will need to deal with
things like fragmentation if you're going to manage a private memory
pool for everything.
-- Regards,Tom Zanussi <zanussi@us.ibm.com> IBM Linux Technology Center/RAS
- 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:35 EST