From: "Thomas Hellström (VMware)" <thomas_os@shipmail.org>
To: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Huge pmds and puds for graphics questions
Date: Thu, 19 Sep 2019 10:53:43 +0200 [thread overview]
Message-ID: <b7b7464a-4ed9-c71d-abf3-07b2af5a2121@shipmail.org> (raw)
Hi!
I'm looking at supporting huge pmds and puds on VM_MIXEDMAPs for the TTM
graphics memory manager. While huge puds might not be that common, huge
pmds will probably be.
We would also want to support vrite-notify vmas, in which case we need
to split the pud / pmds, and handle the write-notification on the pte
level. Today we also support cow mappings, but I'm not sure anyone ever
used it in this context. I figure in this case we just split the huge
puds / pmds and we should be fine.
In any case, over to the questions:
In __handle_mm_fault() we call pmd_alloc() without considering puds
being unstable (somewone faulting in a huge pud entry, or madvise()
removing a huge pud entry). Is there some kind of special mechanism
taking care of that potential race?
https://elixir.bootlin.com/linux/latest/source/mm/memory.c#L3931
In wp_huge_pmd() and wp_huge_pud(), if huge_fault() returns
VM_FAULT_FALLBACK, and there is an existing read-only huge entry, we
don't split that entry, causing the write fault to be endlessly retried.
Is this an oversight or is the huge_fault handler responsible for
splitting the huge entry?
https://elixir.bootlin.com/linux/latest/source/mm/memory.c#L3738
https://elixir.bootlin.com/linux/latest/source/mm/memory.c#L3769
Any insight or comments would be appreciated.
Thanks,
Thomas
reply other threads:[~2019-09-19 8:53 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=b7b7464a-4ed9-c71d-abf3-07b2af5a2121@shipmail.org \
--to=thomas_os@shipmail.org \
--cc=linux-mm@kvack.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