Re: [m5-dev] 8254 PIT (timer device) programming
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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] 8254 PIT (timer device) programming
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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] 8254 PIT (timer device) programming
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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] 8254 PIT (timer device) programming
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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] 8254 PIT (timer device) programming
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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
