| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH] Turn blktap tapfds into a link list
Hi Steven,
thanks for getting to this so quickly! The patch generally looks good -- a
couple of quick thoughts:
- Linear searches of the tapfds list are a little grim where they appear in
the data path (blktap_ioctl, blktap_kick_user, fast_flush_area,
do_block_io_op, dispatch_rw_block_io). If we are happy with a limit of
254 concurrent devices for the immediate term, I wonder if a lookup array
indexed by minor and allocated on use might be better?
- I enjoyed seeing the domid_translate array go away, I think we can kill
this translation all together though by moving the domid/busid lookup
out of blktapctrl and into xenbus, and filling it in directly when a
new vbd is connected.
- With dynamic allocation, MAX_TAP_DEV seems a little unnecessary. Shouldn't
we just allocate until we run out of minors now?
This is a great improvement. I know of at least one person that is regularly
running blktap with 60-80 vbds -- I'd like to get them to try out the patch as
an additional check. Also, because of the changes in allocation and locking
I'm inclined to wait until immediately after the 3.0.3 barrier with this one.
Sound okay?
a.
On 9/28/06, Steven Rostedt <srostedt@xxxxxxxxxx> wrote:
The current implementation of blktap has the tapfds descriptors as a
static array. Which means that what isn't used is taking up memory. It
also means that if we ever want to dynamically increase the number of
descriptors that we allow, we can't do so.
So this patch converts the tapfds from an array into a link list.
I use the list_add_rcu and list_for_each_entry_rcu so that I don't need
to protect the list while walking or adding items to it. I never delete
a device, so once it is added to the list, it stays. But it wouldn't be
hard with the rcu list operations to add a deletion in the future.
This patch also fixed a few bugs that were lying in there. Some where
the tapfds[idx] was offset outside the checking of the idx size
(although they would probably be very hard to hit).
Anyway, I booted this up and it runs. I started a guest with a block
device on the blktap, twice, and there was no problems.
But... I have to admit, I wrote this when I was tired, so it may have
introduced a few bugs as well. I went over it twice, but I could have
missed something twice. Please review! But there shouldn't be anything
major wrong with it.
-- Steve
Signed-off-by: Steven Rostedt <srostedt@xxxxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home