hpet and timer rework

[wjhun]

These changes give us proper HPET support as well as an interval timer to be used for the runloop. Previously, we depended on a single, periodic LAPIC timer which was incorrectly set to a fixed and very long period. (~1s ... configure_timer() was completely ignoring the rate!) This appears to be related to much of the slowness seen with LWIP connection processing (see below).

These changes address improper access of HPET registers (by specification they only allow 32 and 64 bit access, and qemu was ignoring smaller accesses accordingly), implement HPET one-shot and periodic timers, and replace the use of the periodic LAPIC timer with an interval timer within the runloop based on the nearest timeout in the timer heap (or 100ms, whichever is less). While we're at it, crank up the LWIP periodic timer to 100HZ.

with master:

$ time test/network_test 127.0.0.1:8080 -connections 100 -requests 1
c: 100 active: 0 req: 300 resp: 100

real	1m40.539s
user	0m0.028s
sys	0m0.000s

with timer_fix:

$ time test/network_test 127.0.0.1:8080 -connections 100 -requests 1
c: 100 active: 0 req: 300 resp: 100

real    0m1.060s
user    0m0.000s
sys     0m0.028s

[tijoytom-zz]

We can take this out, this does nothing. Infact if you remove this timer all together you gets 10x perf boost. ie 1000 request in 1.2 sec vs 1000 request in 9.8 sec

[tijoytom-zz]

Just to add the usermode perf issue was mostly because of runloop stalling and now since we switched to hpet that goes away.

[wjhun]

• Yes, I did observe that the timer running seems to slow it down somewhat (although much less at 100HZ vs 2HZ). However, according to lwip/doc/rawapi.txt:

• sys_check_timeouts()

  When the system is running, you have to periodically call
  sys_check_timeouts() which will handle all timers for all protocols in
  the stack; add this to your main loop or equivalent.

So I don't think the solution is to just remove it but rather to find out why it's slowing it down. Without this call (or LWIP_TIMERS_CUSTOM should we choose to support it), LWIP has no way to handle timeout-based events.

• I suspect there is a deeper issue with interrupt handling, and turning up the runloop timer frequency is kind of masking it. I'm looking into that now w.r.t. main-loop: WARNING: I/O thread spun for 1000 iterations #114.

[tijoytom-zz]

Make millseconds(100) a const outside the loop, any decent compiler would automatically do it, but just in case..