On 1/15/25 21:39, Gregory Price wrote:
On Wed, Jan 15, 2025 at 06:06:25AM -0600, Donet Tom wrote:
... snip ...
Thank you for taking the time to do this, I don't have enough background
with MGLRU to have done this quickly. I'll pull this onto my branch and
carry it if you don't mind so we can keep things tracked.
I'll send you an updated RFC before i send out v4 and add appropriate tags.
Sure. Thank you.
This difference also impacts read latency:
For MGLRU, the first read shows higher latency due to the combined
overhead of accessing a lower tier and performing promotion.
For LRU, the first 3–4 reads typically exhibit lower latency since
promotion does not occur immediately.
Do you have a thought on a good test we can use to compare these
strategies?
I am also thinking on the same. I will come back with some tests which
can compare these strategies.
We decided against promotion on first-access because there are many
easy-to-imagine scenarios where that will clearly harm performance.
Yes, I agree. After the first access, it gets promoted, but if those pages
are not accessed afterward, it will become an overhead.
I will check if we have any mechanism to restrict it.
We're planning to do some workload testing soon so we can get actual
benefit numbers.
Could you please let me know what workload you are planning?
I can try it on my system as well.
+promo_candid:
+ if (!folio_test_isolated(folio) &&
+ (sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING) &&
+ numa_pagecache_promotion_enabled) {
I am considering putting this in some inline wrapper with some likely()
tags to clean this up a bit and optimize the fall-through cases since
i've seen some measurable differences when left as-is.
Sounds good to me.
Thoughts on this are welcome
+ memcg = folio_memcg(folio);
+ if (memcg) {
Also curious, why only promote when the folio is a member of a memcg?
I missed non memcg pages. I will send a V2 with that.
~Donet
~Gregory
