Russell King wrote:
>Yes, performance. The impact of the extra work for handling the
>setup of the SDRAM allocated by the CFN CPU would hit all functions
>that use the page tables significantly. In this case, the SDRAM
>PCI base should not be modified by the EBSA285.
>
>IMHO, if you're running a machine with the SDRAM located at a fixed
>address in PCI space, you don't really want to have the overhead of
>loading the PCI offset *twice* for each and every PTE reference.
I don't see that it's that big a deal. As far as I can tell, the only place
we need to care what address our memory is mapped to in PCI space is in
virt_to_bus and bus_to_virt. Changing the PCI base address doesn't alter
either the physical address as seen by the local CPU, or the virtual
address where the RAM is mapped. All that changes is how other busmasters see
the local memory.
Where do the page tables come into it? I get the feeling perhaps I'm missing
the point of what you were trying to say. Can you give a concrete example of
where the performance hit is taken?
>In summary, I'm surprised that you're trying to push this when you're
>trying to remove individual CPU cycles else where in the kernel. It
>sounds to me very contradictory.
The actual patch that you were objecting to doesn't add any cycles at all to
any fast-path code. If I'm forgetting about something that means that other
code has to be compile-time conditional on the model in use then so be it, but
that's a different issue.
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
