On 09.04.24 20:41, Yang Shi wrote:
On Thu, Apr 4, 2024 at 12:34 PM David Hildenbrand <david@xxxxxxxxxx> wrote:
On 04.04.24 20:57, Christoph Lameter (Ampere) wrote:
On Mon, 1 Apr 2024, Jonathan Cameron wrote:
Sounds like useful data, but is it a suitable topic for LSF-MM?
What open questions etc is it raising?
mTHP is new functionality that will require additional work to support
more use cases. It is also unclear at this point in what usecases mTHP is
useful and where no benefit can so far be seen. Also the effect of
coalescing multiple PTE entries into one TLB entry is new to MM
(CONT_PTE).
Ultimately it would be useful to have mTHP support also provide larger
blocksize capabilities for filesystem etc etc. mTHP needs to mature and an
analysis of the arguable a bit experimental state of affairs can help a
lot in getting there.
Right, something like that (open items, missed use cases, requirements,
ideas, etc,.) would be a better (good!) fit.
Pure benchmark results, analysis and recommendations are great. But
likely a better fit for a (white) paper, blog post,
less-discussion-focused conference.
Thanks for the suggestion. I didn't plan to enumerate any open items
because I think those items (for example, khugepaged support, swap,
etc) were already well-known by mm community and we have made some
progress on some items.
I think there are two types of open items: "we obviously know what we
have to do -- basic swap, khugepaged, etc. support" and "we don't really
know what to do because it's rather an optimization problem and there
might not be a right or wrong".
The potential future optimization choices led by the benchmark and
analysis may be worth discussing. For example, shall the allocation
fallback should try every single order, is it a good idea to let users
decide the orders, etc. We didn't know what the good choice should be
before we had some benchmark data.
Focusing on such open questions makes a lot of sense. Then, you can use
the benchmark data to guide the discussion and share your insights :)
--
Cheers,
David / dhildenb
