On Wed, 30 Jan 2008, Andrea Arcangeli wrote: > > A user space spinlock plays into this??? That is irrelevant to the kernel. > > And we are discussing "your" placement of the invalidate_range not mine. > > With "my" code, invalidate_range wasn't placed there at all, my > modification to ptep_clear_flush already covered it in a automatic > way, grep from the word fremap in my latest patch you won't find it, > like you won't find any change to do_wp_page. Not sure why you keep > thinking I added those invalidate_range when infact you did.
Well you moved the code at minimum. Hmmm... according http://marc.info/?l=linux-kernel&m=120114755620891&w=2 it was Robin. > The user space spinlock plays also in declaring rdtscp unworkable to > provide a monotone vgettimeofday w/o kernel locking. No idea what you are talking about. > My patch by calling invalidate_page inside ptep_clear_flush guaranteed > that both the thread writing through sptes and the thread writing > through linux ptes, couldn't possibly simultaneously write to two > different physical pages. But then the ptep_clear_flush will issue invalidate_page() for ranges that were already covered by invalidate_range(). There are multiple calls to clear the same spte. > > Your patch allows the thread writing through linux-pte to write to a > new populated page while the old thread writing through sptes still > writes to the old page. Is that safe? I don't know for sure. The fact > the physical page backing the virtual address could change back and > forth, perhaps invalidates the theory that somebody could possibly do > some useful locking out of it relaying on all threads seeing the same > physical page at the same time. This is referrring to the remap issue not do_wp_page right? > Actually above I was describing remap_file_pages not do_wp_page. Ok. The serialization of remap_file_pages does not seem that critical since we only take a read lock on mmap_sem here. There may already be concurrent access to pages from other processors while the ptes are remapped. So there is already some overlap. We could take mmap_sem there writably and keep it writably for the case that we have an mmu notifier in the mm. -- 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/
