Roman,
On Tue, 2006-07-11 at 00:59 +0200, Roman Zippel wrote:
> > The timer interrupt is re-enabled, via the timer_sysclass::resume hook,
> > while the timekeeping code is re-enabled via the
> > timekeeping_sysclass::resume hook. The issue being that I'm not sure
> > there's a defined way to specify the .resume calling order.
> >
> > The timekeeping_suspended flag is a bit heavy handed, but I think it
> > might be the safest bet (assuming Mikael finds it works for him).
>
> As temporary measure it's ok, but please add a comment, that it's there
> because of broken suspend/resume ordering.
> 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.
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.
The majority of machines has stand alone time sources and there is no
need to enforce artificial interrupt relations on them.
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.
tglx
-
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]
