Looking at this more, I'm convinced the Alpha implementation -is-
tracking it's programming. I was confusing the RTC device with the PIT
since it's been a while since I looked at this stuff. The question is
then, what is this periodic interrupt from the RTC used for in Alpha? In
x86 I'm pretty sure it's not used for anything and I'd like to be able
to turn it off intelligently.
Gabe
Gabe Black wrote:
I won't break anything as far as making it not work, but I might
not be able to get exactly the same frequency out of it as before so
the regressions might need to be updated. It shouldn't be a big deal.
Gabe
Ali Saidi wrote:
Just as long as your don't break alpha, yes.
Ali
On May 27, 2008, at 7:18 PM, Gabe Black wrote:
I'm assuming from the lack of response that nobody minds if I do
whatever I think is appropriate. I'm going to send out all the
pending x86 patches once I've reworked some hacks to be done the
"right" way and taken care of a few other things so everybody will
still have a chance to complain.
Gabe
Gabe Black wrote:
I've read the datasheet and I know how the device works, I'm just
trying to figure out what the implementation is doing to emulate
it. There is a base clock that works at some weird frequency which
I think I read was used as a carrier for TV from back when TVs were
used as monitors. The question is whether the interval set as a
parameter is supposed to emulate this frequency in ticks, aka a
clock pulse, or if it's supposed to be the periodic interrupt
signal from the timer finishing counting. In the first case, if an
event gets rescheduled every input clock, that's very inefficient
and something like the timer registers in Alpha/SPARC would be
better. I don't think this is the case. In the later, basically the
registers are so many blinky lights, and there's really just a
periodic interrupt being scheduled. That's fine, if a little
simplistic (not necessarily a bad thing), but I don't know if it's
an accurate enough model for x86 or for kernels that do more
complicated things with it.
The question I really wanted to ask was if and what to do to
increase the fidelity of the model by making the device actually
interrupt according to how it's programmed. That's better from a
correct functionality perspective, but it would possibly make
things harder if you wanted to directly sweep the frequency or
something. I imagine that wouldn't be very likely and you might,
although I haven't actually looked, be able to do that with a
kernel parameter. I didn't bring that up yet because I wanted to
clear up any minor misunderstandings of what was already going on
in the code before I started discussing new ways to mangle it.
Gabe
Ali Saidi wrote:
I imagine it's both, and implementation dependent if an interrupt
occurs when the PIT timer expires, but it's been a long time. I
imagine the datasheet for at 8254 timer would be a good place to
start.
Ali
On May 24, 2008, at 5:40 AM, Gabe Black wrote:
I'm at a point now where the kernel is trying to wait for the
8254 timer to tick 300 times before moving to the local APIC
timer to use for timer interrupts. As we determined before, the
8254 is the same as the PIT used in Alpha Tsunami, so I'm going
to move the Alpha code to a neutral location and use it in x86 as
well. What is the event that the timer schedules? Is that a tick
to update the counter, or is that to fire the periodic interrupt?
If it's the former that seems really inefficient. If it's the
later, then I'm a little concerned that the way the timer is
being programmed by the OS isn't a factor in when it fires. That
would especially be a problem with the tickless kernel where the
timer interrupt doesn't happen all the time. I would imagine that
has to happen by programming the timer not to go off for a while
until it actually needs to.
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
