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
