Messages in this thread | | | Date | Tue, 24 Apr 2007 11:15:26 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH] lazy freeing of memory through MADV_FREE |
| |
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 <riel@redhat.com> > --- > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |