lkml.org 
[lkml]   [2007]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH] lazy freeing of memory through MADV_FREE
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.
--- 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;
\
 
 \ /
  Last update: 2007-04-24 04:57    [W:1.072 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site