lkml.org 
[lkml]   [2005]   [Jun]   [22]   [last100]   RSS Feed
Views: [more markup]   [less markup]   [headers]   [forward]  
 
Messages in this thread
/
DateWed, 22 Jun 2005 11:00:09 -0700
FromNish Aravamudan <>
SubjectRe: -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/

\
 
 \ /
  Last update: 2005-06-22 18:06    [W:0.515 / U:0.320 seconds]
©2003-2008 Jasper Spaans