dank@kegel.com wrote:
>
> Mark Mielke <mark@mark.mielke.cc> wrote:
> >
> > On Wed, Jul 10, 2002 at 04:09:21PM -0600, Cort Dougan wrote:
> > > Yes, please do make it a config option. 10x interrupt overhead makes me
> > > worry. It lets users tailor the kernel to their expected load.
> >
> > All this talk is getting to me.
> >
> > I thought we recently (1 month ago? 2 months ago?) concluded that
> > increases in interrupt frequency only affects performance by a very
> > small amount, but generates an increase in responsiveness. The only
> > real argument against that I have seen, is the 'power conservation'
> > argument. The idea was, that the scheduler itself did not execute
> > on most interrupts. The clock is updated, and that is about all.
>
> On UML and mainframe Linux, *any* periodic clock tick
> is heavy overhead when you have a large number of
> (mostly idle) instances of Linux running, isn't it?
> I think I once heard those architectures went to great lengths
> to avoid periodic clock ticks. (My memory is rusty, though.)
>
> How about this: let's apply the high-resolution timer patch,
> which adds explicit timer events inbetween the normal 100 Hz
> events when needed to satisfy precise sleep requests. Then
> let's increase the interval between the normal periodic clock
> events from 10ms to infinity. Everything will keep working,
> as the high-resolution timer patch code will schedule timer
> events as needed -- but suddenly we'll have power consumption
> as low as possible, snappier performance, and the thousands-of-instances
> case will no longer have this huge drain on performance from
> periodic timer events that do nothing but update jiffiers.
Ah, but you haven't looked at all that happens on a 1/HZ
tick. The high-res-timers patch does NOT eliminate the 1/HZ
tick. That tick is used to do a LOT of accounting activity
which IMHO is best done by a periodic tick. In particular,
the time slice and execution time management depend on the
periodic tick. As a test we put together a tickless system,
much as suggested above, and put enough stuff in it to see
what the overhead was and how it changed. The conclusion
was that the timer over head increased far beyond the
current overhead as soon as the system load (actually the
number of context switches per second) increased beyond what
a moderately busy system experiences. In other words, the
system was overload prone. The current accounting activity
is flat WRT to context switching which is IMHO just what it
should be. For those who want to know, a patch to put that
test system together is still on the HRT sourceforge site.
-g
>
> OK, so I'm just an ignorant member of the peanut gallery, but
> I'd like to hear a real kernel hacker explain why this isn't
> the way to go.
>
> - Dan
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - 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/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:20 EST