To follow up on this, I'm using the CPU frequency divided by 16 as the "bus" frequency used by the local APIC. If anybody thinks that's unreasonable let me know.
Gabe Steve Reinhardt wrote: > > > On Thu, May 22, 2008 at 11:45 AM, Gabe Black <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > One problem is that this isn't a parent/child relationship. For > instance, there could be four CPUs and four local APICs all on the > same bus, and they need to know which one goes with which CPU. In > that case it would be arbitrary. [...] Also, all the local APICs > appear at the same address but are only visible to their CPU. I was > going to try to deal with that by sticking them into their own > address space multiplexed on some address bits, but I don't like the > scalability of that. > > > Yea, that's the kind of thing I meant by "fiddling with address > mappings". I wouldn't disagree that it's a bit hackish, but it seems > plenty scalable to me. If you do that it does solve the "all the APICs > on one local bus" problem too. > > > Another idea is a bus local to the CPU which has the CPU and APIC on > it. That would have to connect to the external interconnect somehow. > That could also be a home for the page table walker and tlb > eventually if those go "off chip" and into the memory system. > > > The tricky part here is doing that without adding latency to non-APIC > memory accesses (and appropriately forwarding flow-control state through > from the cache, etc.). It's probably doable but it would be nicer to > have a more general solution that didn't require this (IMO). > > If the interconnect isn't a bus, then you can't just stick the APICs > anywhere since they're supposed to be tightly integrated on die. > You'd need to make sure they ended up very close to their CPUs, and > having that over a network hop would be substantially unrealistic. > > > Don't forget that part of the point of m5 is to be able to model things > that are "substantially unrealistic", like putting a PCI NIC next to the > L2 cache :-). I think a solution that lets you put the APIC wherever > you want is a good idea, even if most of those places are obviously stupid. > > > I don't think it matters much whether the CPU can check the > interconnect frequency, although it probably can through some > mechanism somewhere like CPUID or the stuff the processor sticks > into PCI config space according to the AMD kernel/BIOS developers > guide. The timer is being setup and used for something, and I would > imagine whatever is using it might break if the frequency is way > off. Then again maybe not. I'd rather make it do what it's supposed > to do than to try to figure out and fix the problems it may cause later. > > > I think the key is separating the stuff that needs to be a certain way > to get things to work from the stuff that is just done a certain way > just because that's easy/traditional/whatever. So clearly the APIC > timer needs to run at a frequency within some range, such that the CPU > can figure out what that frequency is, but I'm guessing that as long as > that frequency is reasonable it doesn't matter exactly what it's > relationship is to the interconnect. So just having a parameter that > lets you set the frequency sounds fine to me; if in the longer term we > find that there really is a need to have it tied to the interconnect > frequency we can always set that up in the python. > > Steve > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
