On Apr 6 2007 07:05, Hugh Dickins wrote:
>On Fri, 6 Apr 2007, Nick Piggin wrote:
>>
>> I like |= for adding flags, it seems less ambiguous. But I guess that's
>> a matter of opinion. Hugh seems to like +=,
>
>Do I? You probably have a shaming example in mind (PAGE_MAPPING_ANON?
>that's a hybrid
Peter Zijlstra wrote:
On Fri, 2007-04-06 at 23:15 +1000, Nick Piggin wrote:
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().
For shared futexes, wouldn't i_mapping be worse, because you'd be
On Fri, 2007-04-06 at 23:15 +1000, Nick Piggin wrote:
> Hugh Dickins wrote:
> > On Fri, 6 Apr 2007, Peter Zijlstra wrote:
> >
> >>some thoughts on shared futexes;
> >>
> >>Could we get rid of the mmap_sem on the shared futexes in the following
> >>manner:
>
> I'd imagine shared futexes would be
Hugh Dickins wrote:
On Fri, 6 Apr 2007, Peter Zijlstra wrote:
some thoughts on shared futexes;
Could we get rid of the mmap_sem on the shared futexes in the following
manner:
I'd imagine shared futexes would be much less common than private for
threaded programs... I'd say we should
On Fri, 2007-04-06 at 14:02 +0100, Hugh Dickins wrote:
> On Fri, 6 Apr 2007, Peter Zijlstra wrote:
> >
> > 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;
>
> ("walk"
On Fri, 6 Apr 2007, Peter Zijlstra wrote:
>
> 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;
("walk" meaning descent down the levels, I presume, rather than across)
I've not
On Thu, 2007-04-05 at 19:49 +0200, Eric Dumazet wrote:
> Hi all
>
> I'm pleased to present this patch which improves linux futexes performance
> and
> scalability, merely avoiding taking mmap_sem rwlock.
>
> Ulrich agreed with the API and said glibc work could start as soon
> as he gets a
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
Eric Dumazet wrote:
Nick Piggin a écrit :
Did the whole thing just turn out neater when you passed the rwsem?
We always know to use current->mm->mmap_sem, so it doesn't seem like
a boolean flag would hurt?
That's a good question
current->mm->mmap_sem being calculated once is a win in
On Fri, 6 Apr 2007, Nick Piggin wrote:
>
> I like |= for adding flags, it seems less ambiguous. But I guess that's
> a matter of opinion. Hugh seems to like +=,
Do I? You probably have a shaming example in mind (PAGE_MAPPING_ANON?
that's a hybrid case where using + and - helped minimize the
On Fri, 6 Apr 2007, Nick Piggin wrote:
I like |= for adding flags, it seems less ambiguous. But I guess that's
a matter of opinion. Hugh seems to like +=,
Do I? You probably have a shaming example in mind (PAGE_MAPPING_ANON?
that's a hybrid case where using + and - helped minimize the
Eric Dumazet wrote:
Nick Piggin a écrit :
Did the whole thing just turn out neater when you passed the rwsem?
We always know to use current-mm-mmap_sem, so it doesn't seem like
a boolean flag would hurt?
That's a good question
current-mm-mmap_sem being calculated once is a win in itself,
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
On Thu, 2007-04-05 at 19:49 +0200, Eric Dumazet wrote:
Hi all
I'm pleased to present this patch which improves linux futexes performance
and
scalability, merely avoiding taking mmap_sem rwlock.
Ulrich agreed with the API and said glibc work could start as soon
as he gets a Fedora
On Fri, 6 Apr 2007, Peter Zijlstra wrote:
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;
(walk meaning descent down the levels, I presume, rather than across)
I've not had time to
On Fri, 2007-04-06 at 14:02 +0100, Hugh Dickins wrote:
On Fri, 6 Apr 2007, Peter Zijlstra wrote:
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;
(walk meaning descent down
Hugh Dickins wrote:
On Fri, 6 Apr 2007, Peter Zijlstra wrote:
some thoughts on shared futexes;
Could we get rid of the mmap_sem on the shared futexes in the following
manner:
I'd imagine shared futexes would be much less common than private for
threaded programs... I'd say we should
On Fri, 2007-04-06 at 23:15 +1000, Nick Piggin wrote:
Hugh Dickins wrote:
On Fri, 6 Apr 2007, Peter Zijlstra wrote:
some thoughts on shared futexes;
Could we get rid of the mmap_sem on the shared futexes in the following
manner:
I'd imagine shared futexes would be much less common
Peter Zijlstra wrote:
On Fri, 2007-04-06 at 23:15 +1000, Nick Piggin wrote:
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().
For shared futexes, wouldn't i_mapping be worse, because you'd be
On Apr 6 2007 07:05, Hugh Dickins wrote:
On Fri, 6 Apr 2007, Nick Piggin wrote:
I like |= for adding flags, it seems less ambiguous. But I guess that's
a matter of opinion. Hugh seems to like +=,
Do I? You probably have a shaming example in mind (PAGE_MAPPING_ANON?
that's a hybrid case
Nick Piggin a écrit :
Hi Eric,
Thanks for doing this... It's looking good, I just have some minor
comments:
Hi Nick, thanks for reviewing.
Eric Dumazet wrote:
*/
-int get_futex_key(void __user *uaddr, union futex_key *key)
+int get_futex_key(void __user *uaddr, union futex_key *key,
+
Hi Eric,
Thanks for doing this... It's looking good, I just have some minor
comments:
Eric Dumazet wrote:
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5-mm4/kernel/futex.c
+++ linux-2.6.21-rc5-mm4-ed/kernel/futex.c
@@ -16,6 +16,9 @@
* Copyright (C) 2006 Red Hat,
On 4/5/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
---
include/linux/futex.h | 45 +-
kernel/futex.c| 294 +---
2 files changed, 230 insertions(+), 109 deletions(-)
I cannot vouch for the whole
? This version is against 2.6.21-rc5-mm4
(so supports 64bit futexes)
In this third version I dropped the NUMA optims and process private hash table,
to let new API come in and be tested.
Thank you
[PATCH] FUTEX : new PRIVATE futexes
Analysis of current linux futex code
On 4/5/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
---
include/linux/futex.h | 45 +-
kernel/futex.c| 294 +---
2 files changed, 230 insertions(+), 109 deletions(-)
I cannot vouch for the whole
Hi Eric,
Thanks for doing this... It's looking good, I just have some minor
comments:
Eric Dumazet wrote:
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
--- linux-2.6.21-rc5-mm4/kernel/futex.c
+++ linux-2.6.21-rc5-mm4-ed/kernel/futex.c
@@ -16,6 +16,9 @@
* Copyright (C) 2006 Red Hat,
Nick Piggin a écrit :
Hi Eric,
Thanks for doing this... It's looking good, I just have some minor
comments:
Hi Nick, thanks for reviewing.
Eric Dumazet wrote:
*/
-int get_futex_key(void __user *uaddr, union futex_key *key)
+int get_futex_key(void __user *uaddr, union futex_key *key,
+
? This version is against 2.6.21-rc5-mm4
(so supports 64bit futexes)
In this third version I dropped the NUMA optims and process private hash table,
to let new API come in and be tested.
Thank you
[PATCH] FUTEX : new PRIVATE futexes
Analysis of current linux futex code
28 matches
Mail list logo
