Re: [RFC] Page table sharing

On February 19, 2002 07:11 pm, Hugh Dickins wrote:

On Tue, 19 Feb 2002, Linus Torvalds wrote:

quoted

On Tue, 19 Feb 2002, Daniel Phillips wrote:

quoted

quoted

At that point you might as well make the TLB shootdown global (ie you keep
track of a mask of CPU's whose TLB's you want to kill, and any pmd that
has count > 1 just makes that mask be "all CPU's").

How do we know when to do the global tlb flush?

See above.

Basically, the algorithm is:

	invalidate_cpu_mask = 0;

	.. for each page swapped out ..

		pte = ptep_get_and_clear(ptep);
		save_pte_and_mm(pte_page(pte));
		mask = mm->cpu_vm_mask;
		if (page_count(pmd_page) > 1)
			mask = ~0UL;
		invalidate_cpu_mask |= mask;

and then at the end you just do

	flush_tlb_cpus(invalidate_cpu_mask);
	for_each_page_saved() {
		free_page(page);
	}

(yeah, yeah, add cache coherency etc).

It's a little worse than this, I think.  Propagating pte_dirty(pte) to
set_page_dirty(page) cannot be done until after the flush_tlb_cpus,

You mean, because somebody might re-dirty an already cleaned page?  Or are
you driving at something more subtle?

if the ptes are writable: and copy_page_range is not setting "cow", so not
write protecting, when it's a shared writable mapping.  Easy answer is
to scrap "cow" there and always do the write protection; but I doubt
that's the correct answer.

Nope.  For shared mmaps you'd get tons of unecessary faults.

swap_out could keep an array of pointers to
ptes, to propagate dirty after flushing TLB and before freeing pages,
but that's not very pretty.

It's not horrible, not worse than the already-existing tlb_remove_page
code anyway.  I think we're not stopped here, just slowed down for some
head scratching.

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/