Re: [PATCH] lazy freeing of memory through MADV_FREE

Rik van Riel
2007-04-24T02:53:49Z

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

Nick Piggin wrote:

> What the tlb flush used to be able to assume is that the page
> has been removed from the pagetables when they are put in the
> tlb flush batch.

I think this is still the case, to a degree. There should be
no harm in removing the TLB entries after the page table has
been unlocked, right?

Or is something like the attached really needed?

From what I can see, the page table lock should be enough
synchronization between unmap_mapping_range, MADV_FREE and
MADV_DONTNEED.

I don't see why we need the attached, but in case you find
a good reason, here's my signed-off-by line for Andrew :)

Signed-off-by: Rik van Riel <riel@redhat.com>

--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.

[-- Attachment #2: linux-2.6-madv_free-flushme.patch --]
[-- Type: text/x-patch, Size: 750 bytes --]

--- linux-2.6.20.x86_64/mm/memory.c.flushme 2007-04-23 22:26:06.000000000 -0400
+++ linux-2.6.20.x86_64/mm/memory.c 2007-04-23 22:42:06.000000000 -0400
@@ -628,6 +628,7 @@ static unsigned long zap_pte_range(struc
long *zap_work, struct zap_details *details)
{
struct mm_struct *mm = tlb->mm;
+ unsigned long start_addr = addr;
pte_t *pte;
spinlock_t *ptl;
int file_rss = 0;
@@ -726,6 +727,11 @@ static unsigned long zap_pte_range(struc

add_mm_rss(mm, file_rss, anon_rss);
arch_leave_lazy_mmu_mode();
+ if (details && details->madv_free) {
+ /* Protect against MADV_DONTNEED or unmap_mapping_range */
+ tlb_finish_mmu(tlb, start_addr, addr);
+ tlb = tlb_gather_mmu(mm, 0);
+ }
pte_unmap_unlock(pte - 1, ptl);

return addr;