Messages in this thread | | | Date | Sat, 16 Jul 2005 17:53:23 -0700 | From | Nishanth Aravamudan <> | Subject | Re: [RFC][PATCH 0/4] new human-time soft-timer subsystem |
| |
On 15.07.2005 [00:28:44 +0200], Roman Zippel wrote: > Hi, > > On Thu, 14 Jul 2005, Nishanth Aravamudan wrote: > > > We no longer use jiffies (the variable) as the basis for determining > > what "time" a timer should expire or when it should be added. Instead, > > we use a new function, do_monotonic_clock(), which is simply a wrapper > > for getnstimeofday(). > > And suddenly a simple 32bit integer becomes a complex 64bit integer, which > requires hardware access to read a timer and additional conversion into ns. > Why is suddenly everyone so obsessed with molesting something simple and > cute as jiffies?
Thanks for the feedback, Roman. I know the 64-bit operations are critical from a performance perspective and may be excessive from a pragmatic perspective. Maybe an alternative would be to only provide *microsecond* resolution in the software, which I currently assume is storable in an unsigned long (a little over an hour?). We could then provide a supplemental interface for those sleeps which would exceed this time, either via looping or a 64-bit parameter for this special interface.
Would that perhaps be a better alternative from the 64-bit perspective?
We could do this one better, perhaps, by basically doing exactly what jiffies does now, but storing a time value (in microseconds) instead of a count of the number of ticks (jiffies' current interpretation). This would perhaps be a 64-bit op, but that is the case current with jiffies_64++ (or jiffies_64 += jiffies_increment). I will work on some patches to do something to this effect and will bring it up during the time/timer talk (Saturday at 13h30).
Thanks again, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |