Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     trondmy@kernel.org
Cc:     linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2 00/16] Readdir enhancements
Date:   Wed, 04 Nov 2020 11:14:51 -0500
Message-ID: <FEA7C67B-4091-4797-B05E-D762F0D0B3A1@redhat.com>
In-Reply-To: <20201103153329.531942-1-trondmy@kernel.org>
References: <20201103153329.531942-1-trondmy@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk

Hi Trond, these look great!

I'm doing some comparison testing before/after this set, and I'm getting
into some memory pressure on a client with 4G ram listing 1.5M dentries 
with
12 char filenames.

It looks like before this set, the readdir code was a bit more resilient 
in
the face of memory pressure, and I'm wondering if we've dropped a call 
to
mark_page_accessed().

* Ben adds:

@@ -460,7 +461,8 @@ static int nfs_readdir_search_array(struct 
nfs_readdir_descriptor *desc)
                 desc->last_cookie = array->last_cookie;
                 desc->current_index += array->size;
                 desc->page_index++;
-       }
+       } else
+               mark_page_accessed(desc->page);
         kunmap_atomic(array);
         return status;
  }

.. no, that's not any better.  I'm still getting evicted pages (or, at
least, low-indexed pages that don't have PageUptodate() set), which 
makes
it nearly impossible to finish listing this directory because we just 
keep
invalidating the mapping.

Any ideas?  I'll keep looking.

Ben