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
> 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.
Linux Technology Development Div.
Server Systems Unit
Xen-devel mailing list