On Mon, Dec 04, 2006 at 01:21:29PM +0100, bert hubert wrote: > On Sun, Dec 03, 2006 at 05:53:23PM -0800, Bill Huey wrote: > > > [8264, 996648, 0] {inode_init_once, fs/inode.c, 196} > > [8552, 996648, 0] {inode_init_once, fs/inode.c, 193} > > Impressive, Bill! > > How tightly is your work bound to -rt? Iow, any chance of separating the > two? Or should we even want to?
Right now, it's solely dependent on -rt, but the basic mechanisms of how it works is pretty much the same as lockdep. Parts of it should be moveable across to regular kernels. The only remaining parts would be altering the lock structure (spinlock, mutex, etc...) to have a pointer that it can use to do the statistical tracking. If it's NULL then it's dunamically allocated and handled differently and allocated when the lock is contended against. There's other uses for it as well. Think about RCU algorithms that need to spin-try to make sure the update of an element or the validation of it's data is safe to do. If an object was created to detect those spins it'll track what is effectively contention as well as it is represented in that algorithm. I've seen an RCU radix tree implementation do something like that. > > The first column is the number of the times that object was contented > > against. > > The second is the number of times this lock object was initialized. The > > third > > is the annotation scheme that directly attaches the lock object (spinlock, > > etc..) in line with the function initializer to avoid the binary tree > > lookup. > > I don't entirely get the third item, can you elaborate a bit? I hate the notion of a search, so I directly set the pointer to a object that's statically defined. It means that the object is directly connected to what is suppose to backing it without doing a runtime search. When that's done, all of the numbers from the second column get moved to the third. > Do you have a feeling of the runtime overhead? There's minimal runtime overhead I believe since it's only doing an atomic increment of the stats during the slowpath before the thread is actually shoved into a wait queue. That's something that happpens seldomly. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/