* Al Viro wrote:
> On Wed, Oct 02, 2013 at 07:13:19AM +0200, Ingo Molnar wrote:
> >
> > * Al Viro wrote:
> >
> > > On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
> > > > Maybe I am missing something obvious ?
> > >
> > > Yes. do_execve_common() starts with unshare_files();
On Wed, Oct 02, 2013 at 07:13:19AM +0200, Ingo Molnar wrote:
>
> * Al Viro wrote:
>
> > On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
> > > Maybe I am missing something obvious ?
> >
> > Yes. do_execve_common() starts with unshare_files(); there can be
> > no other thread
On Wed, Oct 02, 2013 at 07:13:19AM +0200, Ingo Molnar wrote:
* Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
Maybe I am missing something obvious ?
Yes. do_execve_common() starts with unshare_files(); there can be
no other
* Al Viro v...@zeniv.linux.org.uk wrote:
On Wed, Oct 02, 2013 at 07:13:19AM +0200, Ingo Molnar wrote:
* Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
Maybe I am missing something obvious ?
Yes. do_execve_common()
* Al Viro wrote:
> On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
> > Maybe I am missing something obvious ?
>
> Yes. do_execve_common() starts with unshare_files(); there can be
> no other thread capable of modifying that descriptor table.
Btw., might the Android Binder:
On Tue, 2013-10-01 at 23:04 +0100, Al Viro wrote:
> On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
> > Maybe I am missing something obvious ?
>
> Yes. do_execve_common() starts with unshare_files(); there can be
> no other thread capable of modifying that descriptor table.
Hmm,
On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
> Maybe I am missing something obvious ?
Yes. do_execve_common() starts with unshare_files(); there can be
no other thread capable of modifying that descriptor table.
--
To unsubscribe from this list: send the line "unsubscribe
From: Eric Dumazet
On Mon, 2013-09-30 at 18:44 -0700, Linus Torvalds wrote:
> Now, that only gets rid of fd_install(), but I suspect you could do
> something similar for put_unused_fd() (that one does need cmpxchg for
> the "next_fd" thing, though). We'd have to replace the non-atomic
> bitops
From: Eric Dumazet eduma...@google.com
On Mon, 2013-09-30 at 18:44 -0700, Linus Torvalds wrote:
Now, that only gets rid of fd_install(), but I suspect you could do
something similar for put_unused_fd() (that one does need cmpxchg for
the next_fd thing, though). We'd have to replace the
On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
Maybe I am missing something obvious ?
Yes. do_execve_common() starts with unshare_files(); there can be
no other thread capable of modifying that descriptor table.
--
To unsubscribe from this list: send the line unsubscribe
On Tue, 2013-10-01 at 23:04 +0100, Al Viro wrote:
On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
Maybe I am missing something obvious ?
Yes. do_execve_common() starts with unshare_files(); there can be
no other thread capable of modifying that descriptor table.
Hmm, then
* Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
Maybe I am missing something obvious ?
Yes. do_execve_common() starts with unshare_files(); there can be
no other thread capable of modifying that descriptor table.
Btw., might the
On Mon, 2013-09-30 at 20:36 -0700, Eric Dumazet wrote:
> I have a patch mostly working here, and pretty short.
Here is the RFC patch. Unfortunately I cant really give performance
numbers, as a patch like this would need weeks before being tested here.
fs/file.c | 66
On Tue, 2013-10-01 at 04:27 +0100, Al Viro wrote:
> On Mon, Sep 30, 2013 at 07:02:23PM -0700, Linus Torvalds wrote:
>
> > Shouldn't a cmpxchg() in just the dup2 code solve that?
> >
> > If the old value was NULL, you'd have to repeat and go back and see if
> > the open_fds[] bit had been cleared
On Mon, Sep 30, 2013 at 07:02:23PM -0700, Linus Torvalds wrote:
> Shouldn't a cmpxchg() in just the dup2 code solve that?
>
> If the old value was NULL, you'd have to repeat and go back and see if
> the open_fds[] bit had been cleared in the meantime (ie it's NULL not
> because somebody else is
On Mon, 2013-09-30 at 18:44 -0700, Linus Torvalds wrote:
> On Mon, Sep 30, 2013 at 6:05 PM, Eric Dumazet wrote:
> > Speaking of spinlock contention, the files->file_lock is a good example.
> >
> > Multi threaded programs hit this spinlock three times per fd :
>
> ..
On Mon, Sep 30, 2013 at 6:53 PM, Al Viro wrote:
>
> The problem is dup2()
Shouldn't a cmpxchg() in just the dup2 code solve that?
If the old value was NULL, you'd have to repeat and go back and see if
the open_fds[] bit had been cleared in the meantime (ie it's NULL not
because somebody else is
On Mon, Sep 30, 2013 at 06:05:03PM -0700, Eric Dumazet wrote:
> Speaking of spinlock contention, the files->file_lock is a good example.
>
> Multi threaded programs hit this spinlock three times per fd :
>
> alloc_fd() / fd_install() / close()
>
> I think fd_install
On Mon, Sep 30, 2013 at 6:05 PM, Eric Dumazet wrote:
> Speaking of spinlock contention, the files->file_lock is a good example.
>
> Multi threaded programs hit this spinlock three times per fd :
.. do you actually have programs that see contention?
> alloc_fd() / fd_install()
Speaking of spinlock contention, the files->file_lock is a good example.
Multi threaded programs hit this spinlock three times per fd :
alloc_fd() / fd_install() / close()
I think fd_install() could be done without this spinlock.
we want to protect fd_install() from a concurrent res
Speaking of spinlock contention, the files-file_lock is a good example.
Multi threaded programs hit this spinlock three times per fd :
alloc_fd() / fd_install() / close()
I think fd_install() could be done without this spinlock.
we want to protect fd_install() from a concurrent resize
On Mon, Sep 30, 2013 at 6:05 PM, Eric Dumazet eric.duma...@gmail.com wrote:
Speaking of spinlock contention, the files-file_lock is a good example.
Multi threaded programs hit this spinlock three times per fd :
.. do you actually have programs that see contention?
alloc_fd() / fd_install
On Mon, Sep 30, 2013 at 06:05:03PM -0700, Eric Dumazet wrote:
Speaking of spinlock contention, the files-file_lock is a good example.
Multi threaded programs hit this spinlock three times per fd :
alloc_fd() / fd_install() / close()
I think fd_install() could be done without
On Mon, Sep 30, 2013 at 6:53 PM, Al Viro v...@zeniv.linux.org.uk wrote:
The problem is dup2()
Shouldn't a cmpxchg() in just the dup2 code solve that?
If the old value was NULL, you'd have to repeat and go back and see if
the open_fds[] bit had been cleared in the meantime (ie it's NULL not
On Mon, 2013-09-30 at 18:44 -0700, Linus Torvalds wrote:
On Mon, Sep 30, 2013 at 6:05 PM, Eric Dumazet eric.duma...@gmail.com wrote:
Speaking of spinlock contention, the files-file_lock is a good example.
Multi threaded programs hit this spinlock three times per fd :
.. do you actually
On Mon, Sep 30, 2013 at 07:02:23PM -0700, Linus Torvalds wrote:
Shouldn't a cmpxchg() in just the dup2 code solve that?
If the old value was NULL, you'd have to repeat and go back and see if
the open_fds[] bit had been cleared in the meantime (ie it's NULL not
because somebody else is busy
On Tue, 2013-10-01 at 04:27 +0100, Al Viro wrote:
On Mon, Sep 30, 2013 at 07:02:23PM -0700, Linus Torvalds wrote:
Shouldn't a cmpxchg() in just the dup2 code solve that?
If the old value was NULL, you'd have to repeat and go back and see if
the open_fds[] bit had been cleared in the
On Mon, 2013-09-30 at 20:36 -0700, Eric Dumazet wrote:
I have a patch mostly working here, and pretty short.
Here is the RFC patch. Unfortunately I cant really give performance
numbers, as a patch like this would need weeks before being tested here.
fs/file.c | 66
28 matches
Mail list logo
