On 05/13/2015 04:04 AM, Arnd Bergmann wrote:
...
Shall we do the ktime_get_us() approach then? It still requires a
32-bit division like do_gettimeofday(), so it will not be as efficient
as the shifted nanoseconds.
It's no worse, though, right? So I think it's a good transition. Further
optimi
On Tuesday 12 May 2015 21:23:04 Ed Cashin wrote:
> On 05/12/2015 07:14 AM, Arnd Bergmann wrote:
> > On Tuesday 12 May 2015 11:44:21 Arnd Bergmann wrote:
> >> There are of course multiple ways to do this. One way would be to
> >> change the code to work on 32-bit nanoseconds instead of 32-bit
> >> m
On 05/12/2015 05:44 AM, Arnd Bergmann wrote:
On Monday 11 May 2015 21:00:25 Ed Cashin wrote:
...
In that case, there is still information about the timing embedded in
the AoE tag. The send time in jiffies is a rough-grained record of the
send time, and it's extracted from the tag. For these "
On 05/12/2015 07:14 AM, Arnd Bergmann wrote:
On Tuesday 12 May 2015 11:44:21 Arnd Bergmann wrote:
There are of course multiple ways to do this. One way would be to
change the code to work on 32-bit nanoseconds instead of 32-bit
microseconds. This requires proving that the we cannot exceed
4.29 s
Thanks for the expanded motivation. I'll return to your ideas tonight, but I
wanted to mention that it is possible for round trips to take well over five
seconds, partly because the disk on the target might be resetting.
If the rough-grained mechanism in the AoE tag still works, though, that's
On Tuesday 12 May 2015 11:44:21 Arnd Bergmann wrote:
>
> There are of course multiple ways to do this. One way would be to
> change the code to work on 32-bit nanoseconds instead of 32-bit
> microseconds. This requires proving that the we cannot exceed
> 4.29 seconds of round-trip time in calc_rtt
On Monday 11 May 2015 21:00:25 Ed Cashin wrote:
> First, thanks for the patch. I do appreciate the attempt to simplify
> this part of the driver, but I don't think that this patch is good to merge.
>
> I'll make some comments inline below.
>
> On 05/10/2015 10:35 PM, Tina Ruchandani wrote:
> > '
First, thanks for the patch. I do appreciate the attempt to simplify
this part of the driver, but I don't think that this patch is good to merge.
I'll make some comments inline below.
On 05/10/2015 10:35 PM, Tina Ruchandani wrote:
'struct frame' uses two variables to store the sent timestamp -
I would like to see some performance measurements for this patch on a system
with fast storage and multiple 10 GbE links.
If not, at least a good analysis of the expected performance impact the patch
will have on major architectures.
Tonight I will think about whether the 2038 thing even matt
On Monday 11 May 2015 08:05:05 Tina Ruchandani wrote:
> 'struct frame' uses two variables to store the sent timestamp - 'struct
> timeval' and jiffies. jiffies is used to avoid discrepancies caused by
> updates to system time. 'struct timeval' uses 32-bit representation for
> seconds which will ove
'struct frame' uses two variables to store the sent timestamp - 'struct
timeval' and jiffies. jiffies is used to avoid discrepancies caused by
updates to system time. 'struct timeval' uses 32-bit representation for
seconds which will overflow in year 2038.
This patch does the following:
- Replace t
11 matches
Mail list logo
