Messages in this thread | | | Date | Wed, 22 Jun 2005 11:00:09 -0700 | From | Nish Aravamudan <> | Subject | Re: -mm -> 2.6.13 merge status |
| |
On 6/21/05, Nish Aravamudan <nish.aravamudan@gmail.com> wrote: > On 6/21/05, Lee Revell <rlrevell@joe-job.com> wrote: > > On Mon, 2005-06-20 at 23:54 -0700, Andrew Morton wrote: > > > CONFIG_HZ for x86 and ia64: changes default HZ to 250, make HZ > > > Kconfigurable. > > > > > > Will merge (will switch default to 1000 Hz later if that seems > > > necessary) > > > > Are you serious? You're changing the *default* HZ in a stable kernel > > series?!? > > > > This is a big regression, it degrades the resolution of system calls. > > Not that my opinion should sway anybody else, but I really would > prefer more of the in-kernel sleep callers were converted to use > human-time units (and thus were verified to be correct) so that > switching HZ will result in the *same* latencies. How much of moving > to lower HZ values is due to the fact that everything is request 10ms > for 1 jiffy of sleep instead of 1 ms? It's hard to tell if the gain is > there or from the lower frequency of interrupts.
After some further consideration, I don't think that my patches would be at all changed by adjusting HZ's default value. I just want to make sure maintainers are still responsive to appropriate patches to split time-based delays from tick-based delays. So, CONFIG_HZ is ok by me, but I consider it a band-aid.
Thanks, 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/
| |