| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 5 of 9] libxl: only use interactive PyGrub mode w
2011/10/11 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Mon, 2011-10-10 at 15:51 +0100, Roger Pau Monné wrote:
>> > That sounds unfortunate. I agree with you.
>>
>> Well Ian Campbell proposed to use a timeout in select and drop data
>> when the timeout is hit, that what I've implemented in
>>
>> libxl: drop bootloader output if xenconsole file descriptor is not
>> available for writing
>>
>> The patch is quite simple and solves the problem, I don't think it
>> interferes with normal boot process, since a 1s timeout is quite high
>> for data to be delivered from xenconsoled_fd to the user if the
>> console is attached.
>
> The case where a user types
> xl create /a/domain
> xl console adomain
>
> might have a reasonably long delay in it before the console is
> connected. Increasing the libxl buffer size would mitigate that but
> you'd still have the problem of not reading from an fd if the cons is !=
> 0.
>
> Can you print out the actual values of the various producers and
> consumers at the point of the hang? (maybe track total bytes too for
> debug?)
The process gets stuck after writing 1022 bytes to xenconsole_fd, and
the buffer is 24 consumed 48 produced (although that varies, sometimes
I get ~700 produced and ~20 consumed, but the total written bits is
1022 always).
> Perhaps where we have:
> if (xenconsoled_prod == xenconsoled_cons)
> xenconsoled_prod = xenconsoled_cons = 0;
> if (bootloader_prod == bootloader_cons)
> bootloader_prod = bootloader_cons = 0;
> We could also add some suitable memmoves and associated prod/cons
> manipulation, such that the unconsumed data is always pulled to the head
> of the buffer. That might be a reasonably simple way to improve things
> and allow larger buffers to be used? More often than not the memmove
> won't be getting called since either XXX_prod == XXX_cons or XXX_cons is
> already 0, IOW having a partially consumed buffer would be unusual?
I don't really like moving memory around, since it's slow, but I think
implementing a circular buffer would really complicate things. I will
post a new patch that implements the following:
1. Increase buffer.
2. Use memmove to move memory to the head of the buffer and fill it
until the buffer is full.
3. On timeout and full buffer, drop data from the head of the buffer
(older data) and fill it with new data (move the buffer and append new
data at the end).
Do you thing this should be applied to both xenconsoled and
bootloader? since the only one giving problems is xenconsoled.
> Once we have a larger buffer which we always try to fill discarding data
> after a timeout when the buffer is full won't be so critical.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home