Re: [GIT PULL] Orangefs (text only resend)

[Mike Marshall <hubcap@omnibond.com>]

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@omnibond.com> 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@lst.de> 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).