Messages in this thread | | | Date | Thu, 25 Nov 1999 15:51:10 +0000 (GMT) | From | Eleonora Autore <> | Subject | Re: inode_lock "decorative"? |
| |
Hi,
> > The access to last_ino is serialized by spin lock, so that > > it is allowed to be not-atomic. > > > > Real bug is inside grow_inodes(), which calls prune_dcache() in turn. > > And nobody took care of poor dcache in 2.3, so that it stands now > > as bone in throat and all similar operations require big kernel lock.
what is grow_inodes()? I can't see anything called that (in 2.3.30-1). As for prune_dcache() (or shrink_dcache()) it does not seem to be invoked from get_empty_inode() so it is still not clear where the big problem lies.
I.e. get_empty_inode() looks SMP-safe to me. What am I missing?
regards, Tigran.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |