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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/4] new human-time soft-timer subsystem
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? bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 0/4] new human-time soft-timer subsystem
On 14.07.2005 [12:18:41 -0700], john stultz wrote: > Nish has some code, which I hope he'll be sending out shortly that > does just this, converting the soft-timer subsystem to use absolute > time instead of ticks for expiration. I feel it both simplifies the > code and makes it easier to changing the timer interrupt frequency > while the system is running. Here's the set of patches John promised :) 1/4: add jiffies conversion helper functions 2/4: core human-time modifications to soft-timer subsystem 3/4: add new human-time schedule_timeout() functions 4/4: rework sys_nanosleep() to use schedule_timeout_nsecs() The individual patches have more details, but the gist is this: 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(). That is to say, we use uptime in nanoseconds. But, to avoid modifying the existing soft-timer algorithm, we convert the 64-bit nanosecond value to "timerinterval" units. These units are simply 2^TIMEINTERVAL_BITS nanoseconds in length (thus determined at compile time). To sum up, soft-timers now use time (as defined by the timeofday-subsystem) not ticks. Hopefully, the individual e-mails/patches make this change clear. Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 0/4] new human-time soft-timer subsystem
On 14.07.2005 [12:18:41 -0700], john stultz wrote: snip Nish has some code, which I hope he'll be sending out shortly that does just this, converting the soft-timer subsystem to use absolute time instead of ticks for expiration. I feel it both simplifies the code and makes it easier to changing the timer interrupt frequency while the system is running. Here's the set of patches John promised :) 1/4: add jiffies conversion helper functions 2/4: core human-time modifications to soft-timer subsystem 3/4: add new human-time schedule_timeout() functions 4/4: rework sys_nanosleep() to use schedule_timeout_nsecs() The individual patches have more details, but the gist is this: 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(). That is to say, we use uptime in nanoseconds. But, to avoid modifying the existing soft-timer algorithm, we convert the 64-bit nanosecond value to timerinterval units. These units are simply 2^TIMEINTERVAL_BITS nanoseconds in length (thus determined at compile time). To sum up, soft-timers now use time (as defined by the timeofday-subsystem) not ticks. Hopefully, the individual e-mails/patches make this change clear. Thanks, Nish - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/4] new human-time soft-timer subsystem
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? bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
