Christoph's right about the writeback. I'm pretty sure I added the lockdep stuff back to my .config correctly: [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.000000] ... MAX_LOCK_DEPTH: 48 [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 [ 0.000000] ... CLASSHASH_SIZE: 4096 [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 32768 [ 0.000000] ... MAX_LOCKDEP_CHAINS: 65536 [ 0.000000] ... CHAINHASH_SIZE: 32768 [ 0.000000] memory used by lock dependency info: 8159 kB [ 0.000000] per task-struct memory footprint: 1920 bytes After that I ran the dbench setup that our tester guy uses, and then before I left for home I fired off xfstests (Christoph made a xfstest patch for us that at least allows us to run some of it in a meaningful way)... No lockdep backtraces in my syslog this morning... I'll keep looking, and also return to fixing the iov_iter code that Linus pointed out... I hope he looks back in here in the next few day, I guess the merge window ends at the end of this week? Whatever else happens, Al Viro gave me plenty to do <g>... -Mike On Tue, Sep 8, 2015 at 2:21 PM, Mike Marshall <hubcap@xxxxxxxxxxxx> wrote: > Thanks for all the lockdep feedback everyone... > > I used to have some cool things turned on in my .config when > Christoph was working with us... > > CONFIG_DEBUG_SPINLOCK=y > CONFIG_DEBUG_MUTEXES=y > CONFIG_DEBUG_LOCK_ALLOC=y > CONFIG_PROVE_LOCKING=y > > ... and there used to be at thing like this: > CONFIG_LOCKDEP > > ... I guess it is this now? > CONFIG_LOCKDEP_SUPPORT > > Anyhow... I (blush) didn't turn these things on in my VMs when I > got a new desktop recently, I've got them turned back on now... > > -Mike > > On Tue, Sep 8, 2015 at 10:48 AM, Christoph Hellwig <hch@xxxxxx> wrote: >> On Tue, Sep 08, 2015 at 12:22:06AM +0100, Al Viro wrote: >>> You don't want e.g. to have allocation request triggering an attempt to write >>> a dirty page on a shared mapping of a file from your fs while you are holding >>> a mutex that would block that attempt *and* waiting for a allocation to >>> succeed. >> >> Unless something changed very recently there is no writeback in orangefs. >> It's all non-cached I/O straight on to the server, with readpage only >> there for read-only mmaps (for executable I suspect). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
