lkml.org 
[lkml]   [2012]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2012-03-15 20:19    [W:0.060 / U:1.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site