From: Ackerley Tng <ackerleytng@google.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, willy@infradead.org,
sidhartha.kumar@oracle.com, songmuchun@bytedance.com,
vannapurve@google.com, erdemaktas@google.com,
akpm@linux-foundation.org
Subject: Re: [PATCH 1/1] page cache: fix page_cache_next/prev_miss off by one
Date: Tue, 06 Jun 2023 23:35:52 +0000 [thread overview]
Message-ID: <diqzilc0i2p3.fsf@ackerleytng-ctop.c.googlers.com> (raw)
In-Reply-To: <20230606224101.GB4150@monkey> (message from Mike Kravetz on Tue, 6 Jun 2023 15:41:01 -0700)
Mike Kravetz <mike.kravetz@oracle.com> writes:
> On 06/05/23 17:26, Ackerley Tng wrote:
>> Mike Kravetz <mike.kravetz@oracle.com> writes:
>> This doesn't seem to work as expected:
>> Here's a test I did
>> ...
>> The above gave me: page_cache_next_miss(xa, 4, 3): 7
>> But I was expecting a return value of 6.
>> I investigated a little, and it seems like entry at index 6 if we start
>> iterating before 6 is 0xe, and xa_is_internal(entry) returns true.
>> Not yet familiar with the internals of xarrays, not sure what the fix
>> should be.
> I am NOT an expert with xarray. However, the documentation says:
> "Calling xa_store_range() stores the same entry in a range
> of indices. If you do this, some of the other operations will behave
> in a slightly odd way. For example, marking the entry at one index
> may result in the entry being marked at some, but not all of the other
> indices. Storing into one index may result in the entry retrieved by
> some, but not all of the other indices changing."
> This may be why your test is not functioning as expected? I modified
> your check_find_5() routine as follows (within lib/test_xarray.c):
> static noinline void check_find_5(struct xarray *xa, bool mult)
> {
> unsigned long max_scan;
> void *p = &max_scan;
> XA_BUG_ON(xa, !xa_empty(xa));
> if (mult) {
> xa_store(xa, 3, p, GFP_KERNEL);
> xa_store(xa, 4, p, GFP_KERNEL);
> xa_store(xa, 5, p, GFP_KERNEL);
> } else {
> xa_store_range(xa, 3, 5, p, GFP_KERNEL);
> }
> max_scan = 3;
> if (mult)
> printk("---> multiple stores\n");
> else
> printk("---> range store\n");
> printk("page_cache_next_miss(xa, %d, %ld): %ld\n", 4, max_scan,
> __page_cache_next_miss(xa, 4, max_scan));
> if (mult) {
> xa_store(xa, 3, NULL, GFP_KERNEL);
> xa_store(xa, 4, NULL, GFP_KERNEL);
> xa_store(xa, 5, NULL, GFP_KERNEL);
> } else {
> xa_store_range(xa, 3, 5, NULL, GFP_KERNEL);
> }
> xa_destroy(xa);
> }
> This results in:
> [ 149.998676] ---> multiple stores
> [ 149.999391] page_cache_next_miss(xa, 4, 3): 6
> [ 150.003342] ---> range store
> [ 150.007002] page_cache_next_miss(xa, 4, 3): 7
> I am fairly confident the page cache code will make individual xa_store
> calls as opposed to xa_store_range.
I tried this out with xa_store and a non-NULL pointer, and it works as
expected. Thanks!
I also checked that filemap/page_cache doesn't use xa_store_range(). It
only uses xas_store().
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Tested-by: Ackerley Tng <ackerleytng@google.com>
next prev parent reply other threads:[~2023-06-06 23:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230602225747.103865-2-mike.kravetz@oracle.com>
[not found] ` <diqzttvlom5g.fsf@ackerleytng-ctop.c.googlers.com>
2023-06-06 22:41 ` Mike Kravetz
2023-06-06 23:35 ` Ackerley Tng [this message]
2023-05-04 23:38 [PATCH 0/1] fix page_cache_next/prev_miss off by one error Mike Kravetz
2023-05-04 23:38 ` [PATCH 1/1] page cache: fix page_cache_next/prev_miss off by one Mike Kravetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=diqzilc0i2p3.fsf@ackerleytng-ctop.c.googlers.com \
--to=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=erdemaktas@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=sidhartha.kumar@oracle.com \
--cc=songmuchun@bytedance.com \
--cc=vannapurve@google.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox