From: Matthew Wilcox <willy@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Will Deacon <will@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jan Kara <jack@suse.cz>, Minchan Kim <minchan@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Vinayak Menon <vinmenon@codeaurora.org>,
Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
Date: Mon, 14 Dec 2020 18:56:10 +0000 [thread overview]
Message-ID: <20201214185610.GO2443@casper.infradead.org> (raw)
In-Reply-To: <CAHk-=wi80Qp6nZC0yyewhnqvrmPx2h_yWvfq4A25ONb7z9BywQ@mail.gmail.com>
On Mon, Dec 14, 2020 at 09:54:06AM -0800, Linus Torvalds wrote:
> > I expected to hate it more, but it looks reasonable. Opencoded
> > xas_for_each() smells bad, but...
>
> I think the open-coded xas_for_each() per se isn't a problem, but I
> agree that the startup condition is a bit ugly. And I'm actually
> personally more confused by why xas_retry() is needed here, bit not in
> many other places. That is perhaps more obvious now that it shows up
> twice.
>
> Adding Willy to the cc in case he has comments on that, and can
> explain it to me in small words.
>
> [ https://lore.kernel.org/lkml/20201214160724.ewhjqoi32chheone@box/
> for context ]
The xas_retry() is something I now regret, but haven't got annoyed enough
by it yet to fix (also, other projects). It originated in the radix
tree where we would get a radix_tree_node and then iterate over it in
header macros. If we're holding the rcu_read_lock() and somebody else
deletes an entry leaving the entry at index 0 as the only index in the
tree, we tell the RCU readers to rewalk the tree from the top by putting
a retry entry in place of the real entry.
It's not entirely clear to me now why we did that. Just leave the entry
alone and the RCU-walkers will see it, then the rest of the node is empty.
As to why we need to do this in some places and not others; you can
only see a retry entry if you're only protected by the RCU lock. If
you're protected by the spinlock, you can't see any nodes which
contain retry entries.
But I now think we should just get rid of retry entries. Maybe I'm
missing a good reason to keep them.
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Android Kernel Team <kernel-team@android.com>,
Jan Kara <jack@suse.cz>, Minchan Kim <minchan@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Vinayak Menon <vinmenon@codeaurora.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Andrew Morton <akpm@linux-foundation.org>,
Will Deacon <will@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
Date: Mon, 14 Dec 2020 18:56:10 +0000 [thread overview]
Message-ID: <20201214185610.GO2443@casper.infradead.org> (raw)
In-Reply-To: <CAHk-=wi80Qp6nZC0yyewhnqvrmPx2h_yWvfq4A25ONb7z9BywQ@mail.gmail.com>
On Mon, Dec 14, 2020 at 09:54:06AM -0800, Linus Torvalds wrote:
> > I expected to hate it more, but it looks reasonable. Opencoded
> > xas_for_each() smells bad, but...
>
> I think the open-coded xas_for_each() per se isn't a problem, but I
> agree that the startup condition is a bit ugly. And I'm actually
> personally more confused by why xas_retry() is needed here, bit not in
> many other places. That is perhaps more obvious now that it shows up
> twice.
>
> Adding Willy to the cc in case he has comments on that, and can
> explain it to me in small words.
>
> [ https://lore.kernel.org/lkml/20201214160724.ewhjqoi32chheone@box/
> for context ]
The xas_retry() is something I now regret, but haven't got annoyed enough
by it yet to fix (also, other projects). It originated in the radix
tree where we would get a radix_tree_node and then iterate over it in
header macros. If we're holding the rcu_read_lock() and somebody else
deletes an entry leaving the entry at index 0 as the only index in the
tree, we tell the RCU readers to rewalk the tree from the top by putting
a retry entry in place of the real entry.
It's not entirely clear to me now why we did that. Just leave the entry
alone and the RCU-walkers will see it, then the rest of the node is empty.
As to why we need to do this in some places and not others; you can
only see a retry entry if you're only protected by the RCU lock. If
you're protected by the spinlock, you can't see any nodes which
contain retry entries.
But I now think we should just get rid of retry entries. Maybe I'm
missing a good reason to keep them.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-14 18:57 UTC|newest]
Thread overview: 138+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 16:39 [PATCH 0/2] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag Will Deacon
2020-12-09 16:39 ` Will Deacon
2020-12-09 16:39 ` [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting Will Deacon
2020-12-09 16:39 ` Will Deacon
2020-12-09 17:58 ` Linus Torvalds
2020-12-09 17:58 ` Linus Torvalds
2020-12-09 17:58 ` Linus Torvalds
2020-12-09 18:40 ` Will Deacon
2020-12-09 18:40 ` Will Deacon
2020-12-09 19:04 ` Linus Torvalds
2020-12-09 19:04 ` Linus Torvalds
2020-12-09 19:04 ` Linus Torvalds
2020-12-09 20:32 ` Matthew Wilcox
2020-12-09 20:32 ` Matthew Wilcox
2020-12-09 21:04 ` Linus Torvalds
2020-12-09 21:04 ` Linus Torvalds
2020-12-09 21:04 ` Linus Torvalds
2020-12-10 15:08 ` Kirill A. Shutemov
2020-12-10 15:08 ` Kirill A. Shutemov
2020-12-10 17:23 ` Linus Torvalds
2020-12-10 17:23 ` Linus Torvalds
2020-12-10 17:23 ` Linus Torvalds
2020-12-14 16:07 ` Kirill A. Shutemov
2020-12-14 16:07 ` Kirill A. Shutemov
2020-12-14 17:54 ` Linus Torvalds
2020-12-14 17:54 ` Linus Torvalds
2020-12-14 17:54 ` Linus Torvalds
2020-12-14 18:56 ` Matthew Wilcox [this message]
2020-12-14 18:56 ` Matthew Wilcox
2020-12-16 17:07 ` Kirill A. Shutemov
2020-12-16 17:07 ` Kirill A. Shutemov
2020-12-16 18:41 ` Linus Torvalds
2020-12-16 18:41 ` Linus Torvalds
2020-12-16 18:41 ` Linus Torvalds
2020-12-17 10:54 ` Kirill A. Shutemov
2020-12-17 10:54 ` Kirill A. Shutemov
2020-12-17 18:22 ` Linus Torvalds
2020-12-17 18:22 ` Linus Torvalds
2020-12-17 18:22 ` Linus Torvalds
2020-12-18 11:04 ` Kirill A. Shutemov
2020-12-18 11:04 ` Kirill A. Shutemov
2020-12-18 18:56 ` Linus Torvalds
2020-12-18 18:56 ` Linus Torvalds
2020-12-18 18:56 ` Linus Torvalds
2020-12-19 12:41 ` Kirill A. Shutemov
2020-12-19 12:41 ` Kirill A. Shutemov
2020-12-19 20:08 ` Linus Torvalds
2020-12-19 20:08 ` Linus Torvalds
2020-12-19 20:08 ` Linus Torvalds
2020-12-19 20:34 ` Linus Torvalds
2020-12-19 20:34 ` Linus Torvalds
2020-12-19 20:34 ` Linus Torvalds
2020-12-22 10:00 ` Kirill A. Shutemov
2020-12-22 10:00 ` Kirill A. Shutemov
2020-12-24 4:04 ` Hugh Dickins
2020-12-24 4:04 ` Hugh Dickins
2020-12-24 4:04 ` Hugh Dickins
2020-12-25 11:31 ` Kirill A. Shutemov
2020-12-25 11:31 ` Kirill A. Shutemov
2020-12-26 17:57 ` Linus Torvalds
2020-12-26 17:57 ` Linus Torvalds
2020-12-26 17:57 ` Linus Torvalds
2020-12-26 20:43 ` Kirill A. Shutemov
2020-12-26 20:43 ` Kirill A. Shutemov
2020-12-26 21:03 ` Hugh Dickins
2020-12-26 21:03 ` Hugh Dickins
2020-12-26 21:03 ` Hugh Dickins
2020-12-26 21:16 ` Linus Torvalds
2020-12-26 21:16 ` Linus Torvalds
2020-12-26 21:16 ` Linus Torvalds
2020-12-26 22:40 ` Kirill A. Shutemov
2020-12-26 22:40 ` Kirill A. Shutemov
2020-12-27 0:45 ` Hugh Dickins
2020-12-27 0:45 ` Hugh Dickins
2020-12-27 0:45 ` Hugh Dickins
2020-12-27 2:38 ` Hugh Dickins
2020-12-27 2:38 ` Hugh Dickins
2020-12-27 2:38 ` Hugh Dickins
2020-12-27 19:38 ` Linus Torvalds
2020-12-27 19:38 ` Linus Torvalds
2020-12-27 19:38 ` Linus Torvalds
2020-12-27 20:32 ` Damian Tometzki
2020-12-27 20:32 ` Damian Tometzki
2020-12-27 22:35 ` Hugh Dickins
2020-12-27 22:35 ` Hugh Dickins
2020-12-27 22:35 ` Hugh Dickins
2020-12-27 23:12 ` Linus Torvalds
2020-12-27 23:12 ` Linus Torvalds
2020-12-27 23:12 ` Linus Torvalds
2020-12-27 23:40 ` Linus Torvalds
2020-12-27 23:40 ` Linus Torvalds
2020-12-27 23:40 ` Linus Torvalds
2020-12-27 23:55 ` Kirill A. Shutemov
2020-12-27 23:55 ` Kirill A. Shutemov
2020-12-27 23:48 ` Kirill A. Shutemov
2020-12-27 23:48 ` Kirill A. Shutemov
2020-12-28 1:54 ` Linus Torvalds
2020-12-28 1:54 ` Linus Torvalds
2020-12-28 1:54 ` Linus Torvalds
2020-12-28 6:43 ` Hugh Dickins
2020-12-28 6:43 ` Hugh Dickins
2020-12-28 6:43 ` Hugh Dickins
2020-12-28 12:53 ` Kirill A. Shutemov
2020-12-28 12:53 ` Kirill A. Shutemov
2020-12-28 18:47 ` Linus Torvalds
2020-12-28 18:47 ` Linus Torvalds
2020-12-28 18:47 ` Linus Torvalds
2020-12-28 21:58 ` Linus Torvalds
2020-12-28 21:58 ` Linus Torvalds
2020-12-28 21:58 ` Linus Torvalds
2020-12-29 13:28 ` Kirill A. Shutemov
2020-12-29 13:28 ` Kirill A. Shutemov
2020-12-29 15:19 ` Matthew Wilcox
2020-12-29 15:19 ` Matthew Wilcox
2020-12-29 20:52 ` Linus Torvalds
2020-12-29 20:52 ` Linus Torvalds
2020-12-29 20:52 ` Linus Torvalds
2020-12-28 22:05 ` Kirill A. Shutemov
2020-12-28 22:05 ` Kirill A. Shutemov
2020-12-28 22:12 ` Kirill A. Shutemov
2020-12-28 22:12 ` Kirill A. Shutemov
2020-12-29 4:35 ` Hugh Dickins
2020-12-29 4:35 ` Hugh Dickins
2020-12-29 4:35 ` Hugh Dickins
2020-12-28 23:28 ` Linus Torvalds
2020-12-28 23:28 ` Linus Torvalds
2020-12-28 23:28 ` Linus Torvalds
2020-12-26 21:07 ` Linus Torvalds
2020-12-26 21:07 ` Linus Torvalds
2020-12-26 21:07 ` Linus Torvalds
2020-12-26 21:41 ` Matthew Wilcox
2020-12-26 21:41 ` Matthew Wilcox
2020-12-09 16:39 ` [PATCH 2/2] arm64: mm: Implement arch_wants_old_faultaround_pte() Will Deacon
2020-12-09 16:39 ` Will Deacon
2020-12-09 18:35 ` Catalin Marinas
2020-12-09 18:35 ` Catalin Marinas
2020-12-09 18:46 ` Will Deacon
2020-12-09 18:46 ` Will Deacon
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=20201214185610.GO2443@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=jack@suse.cz \
--cc=kernel-team@android.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vinmenon@codeaurora.org \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.