Hi,
On Tue, 11 Jul 2006, Thomas Gleixner wrote:
> > That's another reason why I think that keeping interrupt handling and
> > timekeeping separate is illusionary.
>
> It is not illusionary at all and we have to find a way to handle this.
>
> Forcing time keeping to be bound on some interrupt handling is the wrong
> design and in the way of tickless systems.
So what is the correct design?
Especially for tickless system it's vital for precise timekeeping that the
timekeeping code knows what the timer interrupt code does.
> When there is a system where the time source is bound to an interrupt
> event then the handling code for that time source has to cope with the
> problem instead of enforcing this not generally valid scenario on
> everything. We can of course add helpers into the generic part of the
> time keeping code to make this easier.
I'm not sure I'm following, could you please illustrate with an example?
> The majority of machines has stand alone time sources and there is no
> need to enforce artificial interrupt relations on them.
What do you mean with "artificial interrupt relations"?
> Please accept that the "tick" is not the holy grail of Linux. We have
> already way too much historic tick ballast all over the place, so we
> really want to avoid that when we design replacement functionality.
What do you mean with the "holy grail" of "tick"?
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
