Re: [PATCH] lazy freeing of memory through MADV_FREE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rik van Riel wrote:
Use TLB batching for MADV_FREE.  Adds another 10-15% extra performance
to the MySQL sysbench results on my quad core system.

Signed-off-by: Rik van Riel <[email protected]>
---

Nick Piggin wrote:

3) because of this, we can treat any such accesses as
   happening simultaneously with the MADV_FREE and
   as illegal, aka undefined behaviour territory and
   we do not need to worry about them


Yes, but I'm wondering if it is legal in all architectures.


It's similar to trying to access memory during an munmap.

You may be able to for a short time, but it'll come back to
haunt you.

The question is whether the architecture specific tlb
flushing code will break or not.


4) because we flush the tlb before releasing the page
   table lock, other CPUs cannot remove this page from
   the address space - they will block on the page
   table lock before looking at this pte


We don't when the ptl is split.


Even then we do.  Each invocation of zap_pte_range() only touches
one page table page, and it flushes the TLB before releasing the
page table lock.

What kernel are you looking at? -rc7 and rc6-mm1 don't, AFAIKS.

--
SUSE Labs, Novell Inc.
-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux