Changed the way timers are collected per Julia and Thomas'recommendation: Expired timers are now collected in interrupt contextand fired in ktimersoftd to avoid double-walk of `pending_map`.

This is implemented by storing lists of expired timers in timer_base,which carries a memory overhead 9*sizeof(pointer) per CPU. The timersystem uses hlist's which don't have end-node references, making itimpossible to merge 2 hlist's in constant time. I.e. Merging requireswalking one list. I also considered switching `vectors` to regularlist's which don't have this limitations, but that approach has the samememory overhead. list_head is bigger than hlist_head by sizeof(pointer)and is instantiated 9+ times per CPU as `vectors`. I believe the onlyway to trim overhead is to spend more CPU cycles in interrupt contexteither in list merging (unbounded operation) or the original double-walkimplementation. Any suggestions/preferences?

As before, a 6h run of cyclictest without CPU affinity shows decrease in22-70us latency range. No change in max jitter. No change when `-S` isused.

I'm relatively new to the timer subsystem, so please feel free to pokeas many holes as possible in this change. A few things that concern meat the moment are:

Can jiffies change while one or more cpus is inside tick_sched_timer(), in interrupt context? I'm copying jiffies to a local variable in find_expired_timers() to ensure it doesn't run unbounded, but I'm not sure if that's necessary.

Any special considerations for testing NO_HZ builds? (Other than lettingit run idle for a while)

timers_dead_cpu() presently asserts no timer callback is activelyrunning, which suggests that timers must be canceled prior to disablingCPUs; otherwise, there's a race between active timers and hotplugwhich can crash the whole kernel. Is this a safe assumption to make andare there any special considerations for CPU hotplug testing?