On Tue, Sep 21, 2010 at 12:57:35PM -0300, Christian Robottom Reis wrote:
On Mon, Sep 20, 2010 at 10:35:52AM -0700, Paul E. McKenney wrote:
I still have two questions about stuff that came up here:
- SD/MMC performance: Is this about device access, file systems or both? I think the file system level stuff is actually the more important part but I fear that what was discussed is the other one.
The discussion didn't get into that level of detail. :-(
That's not reason for a frownie. The TSC discussion is /meant/ to be high-level; if you want customer input on what to focus on we can reach out to them, but otherwise just measure and optimize. IOW, you get to choose what the most important part is.
Fair enough. My point was that the answer was not known, so that work would need to be done to find the answer.
- highmem: Not sure what this was about. I guess we don't really want to enable this by default, but some people will want it anyway. Is this about run-time patching the code out of the kernel?
I believe that this is related to LPAE -- the usual 32-bit-only DMA devices in a >32-bit physical address space. But there was also discussion about run-time patching for SMP alternatives, though I am missing how this relates to highmem. Enlightenment?
(Highmem is not just for LPAE, as we discussed earlier it's also important to support configurations with more than 1GB if you preserve the 1/3 memory split.)
There's was relationship between runtime UP detection and highmem discussed in the meeting; the bigger point here is that we want to ensure the kernel is stellar at supporting our architectural baseline: platforms that are V7-A, SMP, NEON and larger-than-traditional-embedded memory profiles.
Thank you for the info!
Thanx, Paul