I'm about to leave for the day... I haven't found any problems with the GFP_KERNEL allocations that Al warned me about... that doesn't mean there aren't any... I'm using copy_page_to_iter in my new branch as Al suggested. I've changed the code quite a bit from any samples I've posted, there were regressions with it. I finally stole some code from cifs/file.c/cifs_readdata_to_iov and everything works... but I'm not happy with it yet... Linus once posted a message to the effect that "you don't fix bugs by thrashing around until stuff seems to work, you fix them by doing the right thing on purpose..." and I'm working towards that end... Anyhow, what's in Linux next continues to pass all our tests, though the code needs improved in the ways mentioned by Al and Linus... I guess the merge window ends today? -Mike On Wed, Sep 9, 2015 at 11:05 AM, Mike Marshall <hubcap@xxxxxxxxxxxx> wrote: > 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
