On Wed, 2 Mar 2005, Andrew Morton wrote: > > There have been extensive discussions on all aspects of this patch. > > This issue was discussed in > > http://marc.theaimsgroup.com/?t=110694497200004&r=1&w=2 > > This is a difficult, intrusive and controversial patch. Things like the > above should be done in a separate patch. Not only does this aid > maintainability, it also allows the change to be performance tested in > isolation.
Well it would have been great if this was mentioned in the actual discussion at the time. > > The cmpxchg will fail if that happens. > > How about if someone does remap_file_pages() against that virtual address > and that syscalls happens to pick the same physical page? We have the same > physical page at the same pte slot with different contents, and the cmpxchg > will succeed. Any mmap changes requires the mmapsem. > > http://marc.theaimsgroup.com/?l=linux-kernel&m=110272296503539&w=2 > > Those are different cases. I still don't see why the change is justified in > do_swap_page(). Lets undo that then. > > These architectures have the atomic pte's not enable. It would require > > them to submit a patch to activate atomic pte's for these architectures. > > > But if the approach which these patches take is not suitable for these > architectures then they have no solution to the scalability problem. The > machines will perform suboptimally and more (perhaps conflicting) > development will be needed. They can implement their own approach with the provided hooks. You could for example use SSE / MMX for atomic 64 bit ops on i386 with PAE mode by using the start/stop macros to deal with the floatingh point issues. > > One > > would have to check for the lock being active leading to significant code > > changes. > > Why? Because if a pte is locked it should not be used. Look this is an endless discussion with new things brought up at every corner and I have reworked the patches numerous times. Could you tell me some step by step way that we can finally deal with this? Specify a sequence of patches and I will submit them to you step by step. - 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/