On 09/07/2013 02:07 PM, Al Viro wrote:
On Sat, Sep 07, 2013 at 10:52:02AM -0700, Linus Torvalds wrote:
So I think we could make a more complicated data structure that looks
something like this:
struct seqlock_retry {
unsigned int seq_no;
int state;
};
and pass that aroun
On Sun, 2013-09-08 at 05:58 +0100, Al Viro wrote:
> On Sun, Sep 08, 2013 at 12:15:46PM +0800, Ian Kent wrote:
> > > and *name is never modified in it. Why not simply pass it by value?
> > > Moreover, I'm not sure I understand what do we need sbi->fs_lock in
> > > there. Other than that, it's very
On Sun, Sep 08, 2013 at 12:15:46PM +0800, Ian Kent wrote:
> > and *name is never modified in it. Why not simply pass it by value?
> > Moreover, I'm not sure I understand what do we need sbi->fs_lock in
> > there. Other than that, it's very close to dentry_path() (well, that
> > and different call
On Sat, 2013-09-07 at 18:32 +0100, Al Viro wrote:
> On Sat, Sep 07, 2013 at 04:01:10AM +0100, Al Viro wrote:
> > * plain seqretry loop (d_lookup(), is_subdir(), autofs4_getpath(),
> > ceph_misc_build_path(), [cifs] build_path_from_dentry(), nfs_path(),
> _mds_, actually - sorry.
> > [audi
On Sat, Sep 07, 2013 at 07:07:24PM +0100, Al Viro wrote:
> with these loops turning into
> seq = read_seqlock(&rename_lock);
again:
> ...
> if (!seqretry_and_lock(&rename_lock, &seq))
> goto again;
> ...
> seqretry_done(&rename_lock);
Forgot the label,
On Sat, Sep 07, 2013 at 10:52:02AM -0700, Linus Torvalds wrote:
> So I think we could make a more complicated data structure that looks
> something like this:
>
>struct seqlock_retry {
> unsigned int seq_no;
> int state;
>};
>
> and pass that around. Gcc should do pretty well
On Fri, Sep 6, 2013 at 8:01 PM, Al Viro wrote:
>
> * plain seqretry loop (d_lookup(), is_subdir(), autofs4_getpath(),
> ceph_misc_build_path(), [cifs] build_path_from_dentry(), nfs_path(),
> [audit] handle_path())
> * try seqretry once, then switch to write_seqlock() (the things
>
On Sat, Sep 07, 2013 at 04:01:10AM +0100, Al Viro wrote:
> * plain seqretry loop (d_lookup(), is_subdir(), autofs4_getpath(),
> ceph_misc_build_path(), [cifs] build_path_from_dentry(), nfs_path(),
_mds_, actually - sorry.
> [audit] handle_path())
> * try seqretry once, then switch
On Fri, Sep 06, 2013 at 05:58:51PM -0700, Linus Torvalds wrote:
> On Fri, Sep 6, 2013 at 5:19 PM, Linus Torvalds
> wrote:
> >
> > (We're bounded in practice by PATH_MAX, so you can't make getcwd()
> > traverse more than about 2000 parents (single character filename plus
> > the slash for each leve
On 09/06/2013 04:52 PM, Linus Torvalds wrote:
On Fri, Sep 6, 2013 at 9:08 AM, Waiman Long wrote:
This patch will replace the writer's write_seqlock/write_sequnlock
sequence of the rename_lock of the callers of the prepend_path() and
__dentry_path() functions with the reader's read_seqbegin/read
On Fri, Sep 6, 2013 at 5:19 PM, Linus Torvalds
wrote:
>
> (We're bounded in practice by PATH_MAX, so you can't make getcwd()
> traverse more than about 2000 parents (single character filename plus
> the slash for each level), and for all I know filesystems might cap it
> before that, so it's not u
On Fri, Sep 6, 2013 at 5:00 PM, Al Viro wrote:
>
> Er... what will happen if you have done just what you've described and have
> a process call d_lookup()?
Umm. Yes?
What part of "one single path component" did you not get?
To repeat: d_lookup() NEVER LOOKS UP A WHOLE PATHNAME. It looks up
just
On Fri, Sep 06, 2013 at 02:48:32PM -0700, Linus Torvalds wrote:
> On Fri, Sep 6, 2013 at 2:05 PM, Al Viro wrote:
> >
> > I can take that, but I'm really not convinced that we need writer lock
> > there at all. After all, if we really can get livelocks on that one,
> > we would be getting them on
On Fri, Sep 6, 2013 at 2:05 PM, Al Viro wrote:
>
> I can take that, but I'm really not convinced that we need writer lock
> there at all. After all, if we really can get livelocks on that one,
> we would be getting them on d_lookup()...
d_lookup() does a _single_ path component. That's a *big* d
On Fri, Sep 6, 2013 at 9:08 AM, Waiman Long wrote:
>
> This patch will replace the writer's write_seqlock/write_sequnlock
> sequence of the rename_lock of the callers of the prepend_path() and
> __dentry_path() functions with the reader's read_seqbegin/read_seqretry
> sequence within these 2 funct
On Fri, Sep 06, 2013 at 01:52:49PM -0700, Linus Torvalds wrote:
> Al - do you have comments? Do you want to take this through your tree,
> or are you working on other things? I can take this directly too..
I can take that, but I'm really not convinced that we need writer lock
there at all. Afte
When running the AIM7's short workload, Linus' lockref patch eliminated
most of the spinlock contention. However, there were still some left:
8.46% reaim [kernel.kallsyms] [k] _raw_spin_lock
|--42.21%-- d_path
| proc_pid_readlink
17 matches
Mail list logo
