On Wed, 2 Mar 2005, Andrew Morton wrote: > > There should be no change to these arches > > But we must at least confirm that these architectures can make these > changes in the future. If they make no changes then they haven't > benefitted from the patch. And the patch must be suitable for all > architectures which might hit this scalability problem. > > > Could we at least get the first two patches in? I can then gradually > > address the other issues piece by piece. > > The atomic ops patch should be coupled with the main patch series. The mm > counter one we could sneak in beforehand, I guess.
The atomic ops patch basically just avoids doing a pte_clear and then setting the pte for archs that define CONFIG_ATOMIC_TABLE_OPS. This is unecessary on ia64 and ia32 AFAIK. > > > The necessary more sweeping design change can be found at > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=110922543030922&w=2 > > > > but these may be a long way off. > > Yes, that seemed sensible, although it may not work out to be as clean as > it appears. Of course. But at least we would like to start as clean as possible. > But how would that work allow us to address page_table_lock scalability > problems? Because the actual locking method is abstracted in a transaction (idea by Nick Piggins, I just tried to make it cleaner). The arch may use pte locking, pmd locking, atomic ops or whatever to provide synchronization for page table operations. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
