[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Patch 0/7] pvSCSI driver



Hi James-san,

On Thu, 21 Feb 2008 14:39:47 +1100
"James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:
> Just responding to myself, would I be guessing correctly that you
> removed the timeout field to make the request structure smaller? The top

That is one reason. However, the main reason is as follows.

The time that guests/host will get is not real world's time on
virtualized environment. The time depends on hypervisor's scheduling.
(Is this assumption right ?)

For example, if upper layer of the pvSCSI frontend specified 5 seconds
as timeout, it should be treated as real world's time or within a guest
domain's world time ?

We didn't have clear answer when we implemented that part. Therefore,
we coded it temporally 5 seconds.

James-san, how do you think about this issue ?

By the way, we understand that the 5 seconds is too short to support
tape device.

Best regards,


> byte of the request_bufflen field could be used as a timeout, as
> sensible timeout values don't need to be very exact. Even if we just
> used the top 4 bits and made it (1 << (timeout + 1)) * 5 * HZ, that
> would give us a bit over 45 hours, and we'd make 15 mean infinite.
> 
> By my calculations, the largest that bufflen could be is 27 * PAGE_SIZE
> = ~110K on x86, so we have plenty of headroom.
> 
> With the timeout increased, the HP Library & Tape Tools have
> successfully completed a 'LTO Drive Assessment test' under Windows.
> 
> James
> 

Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@xxxxxxxxxxxxxx



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.