Messages in this thread | | | Date | Thu, 15 Mar 2012 20:17:12 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [patch 0/5] seqlock consolidation |
| |
On Thu, 15 Mar 2012, Al Viro wrote:
> On Thu, Mar 15, 2012 at 06:55:18PM +0100, Thomas Gleixner wrote: > > > If that's it, I suggest to look for a solution that would express just that... > > > Or do you want something on the reader side as well? > > > > The problem is the reader side. If the reader preempts the writer then > > the only way to make progress is to take the lock, but therefor I need > > to know which lock I should take. > > So just make writers non-preemptable in those sections. Really, the > worst non-deterministic behaviour you get for d_seq ones is memcpy() > of up to ->d_name.len bytes. And on the fs_struct side it's trivial > to reduce the work done in those sections to several comparisons and > assignments. Not even path_get_longterm() needs to be there - see > below for how it can be done:
Yeah, path_get_longterm() was what worried me due to dget() taking d_lock, but yeah, I'm happy to avoid all that churn that way.
Thanks a lot!
> if (fs) { > + int hits = 0; > spin_lock(&fs->lock); > write_seqcount_begin(&fs->seq); > - if (fs->root.dentry == old_root->dentry > - && fs->root.mnt == old_root->mnt) { > - path_get_longterm(new_root); > - fs->root = *new_root; > + hits += replace_path(&fs->root, old_root, new_root); > + hits += replace_path(&fs->pwd, old_root, new_root);
Wouldn't it be simpler to just do:
+ count += replace_path(&fs->root, old_root, new_root); + count += replace_path(&fs->pwd, old_root, new_root);
> + write_seqcount_end(&fs->seq); > + while (hits--) { > count++;
Instead of that loop ?
Thanks,
tglx
| |