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
