On Mon, 2014-02-24 at 17:11 -0800, Eric Dumazet wrote:

On Mon, 2014-02-24 at 15:51 -0800, Stephen Hemminger wrote:

quoted

The original reason I kept ms resolution and added the flag was
that accessing high resolution time is expensive for systems where
TSC is not stable.  Google may live in a world of SMP systems with
good X86 CPUs with working TSC, but other architectures and system
config's may have non-working TSC.

Well, it seems we now have alternatives to ktime_get() that were
probably not yet there at the time you made this choice ?

We only want a reasonable alternative to jiffies based measures,
we do not need ultra precise and synchronized clocks.

I'll redo tests with hpet clocksource, and local_clock()

Interesting : Using current net-next kernel, before my patches I get
on a TCP_RR workload :

It seems nobody is seriously using hpet these days with recent kernels.


    29.98%  [kernel]      [k] read_hpet                     
     2.93%  [kernel]      [k] _raw_spin_lock                
     1.63%  [kernel]      [k] __schedule                    
     1.62%  [bnx2x]       [k] bnx2x_start_xmit              
     1.57%  [kernel]      [k] __netif_receive_skb_core      
     1.45%  [kernel]      [k] tcp_ack                       
     1.30%  [kernel]      [k] idle_cpu                      
     1.29%  [kernel]      [k] __switch_to                   
     1.28%  netperf       [.] send_omni_inner               
     1.05%  libc-2.15.so  [.] __libc_recv                   
     0.98%  [kernel]      [k] ipv4_dst_check