Re: [PATCH 4/25]: Cheaper & smaller timestamping

[Gerrit Renker <gerrit@erg.abdn.ac.uk>]

Quoting Arnaldo Carvalho de Melo:
|  > I have tested on various i386 instances (where it is `long') and on sparc64 (where it is `int', as
|  > in parisc).  I was just calculating - there is indeed a chance to produce overflow, since we add
|  > in timeval_add_usecs (since it is a signed type, the same problem seems to reappear in timeval_sub_usecs).
|  >
|  > I don't have accurate figures at the moment with regard to overflow, but I assume that it is better to revert
|  > this patch?
|  >
|  > There is a related question  - with the new timesystem, should we convert to __get_realtime_clock_ts(), as
|  > the comment above do_gettimeofday() says in kernel/timer.c ?
|  >
|  > I would be glad for clarification, since there are quite a few patches to update.
|  
|  I'd say leave the dccp_timestamp alone for now, I have to read a bit
|  more on the new time system and what was done on the net schedulers,
|  etc before being able to say something meaningful on this aspect.
|  
Just to be on the safe side then I will revert this patch 4/25 so that everything again uses dccp_epoch, ok?