[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1175862369.6483.173.camel@twins>
Date: Fri, 06 Apr 2007 14:26:09 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Eric Dumazet <dada1@...mosbay.com>
Cc: Ulrich Drepper <drepper@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Dave Jones <davej@...hat.com>,
Nick Piggin <nickpiggin@...oo.com.au>,
Ingo Molnar <mingo@...e.hu>, Andi Kleen <ak@...e.de>,
Ravikiran G Thirumalai <kiran@...lex86.org>,
"Shai Fultheim (Shai@...lex86.org)" <shai@...lex86.org>,
pravin b shelar <pravin.shelar@...softinc.com>,
linux-kernel@...r.kernel.org, hugh <hugh@...itas.com>,
"Pierre.Peiffer" <Pierre.Peiffer@...l.net>
Subject: Shared futexes (was [PATCH] FUTEX : new PRIVATE futexes)
Hi,
some thoughts on shared futexes;
Could we get rid of the mmap_sem on the shared futexes in the following
manner:
- do a page table walk to find the pte;
- get a page using pfn_to_page (skipping VM_PFNMAP)
- get the futex key from page->mapping->host and page->index
and offset from addr % PAGE_SIZE.
or given a key:
- lookup the page from key.shared.inode->i_mapping by key.shared.pgoff
possibly loading the page using mapping->a_ops->readpage().
then:
- perform the futex operation on a kmap of the page
This should all work except for VM_PFNMAP.
Since the address is passed from userspace we cannot trust it to not
point into a VM_PFNMAP area.
However, with the RCU VMA lookup patches I'm working on we could do that
check without holding locks and without exclusive cachelines; the
question is, is that good enough?
Or is there an alternative way of determining a pfnmap given a
pfn/struct page?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists