Re: [LSF/MM/BPF TOPIC] Unifying sources of page temperature information - what info is actually wanted?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16-Feb-25 12:19 PM, Huang, Ying wrote:

1) Give me up to X hotish pages from a slow tier (greater than a specific measure
of temperature)

Because the hot pages may be available upon page accessing (such PROT_NONE
page fault), the interface may be "push" style instead of "pull" style,
e.g.,

int register_hot_page_handler(void (*handler)(struct page *hot_page, int temperature));

Yes, push model appears natural to me given that there are producers who are themselves consumers as well.

Let's take an example of access being detected by PTE scan by DAMON first and LRU and hot page promotion subsystems have registered handlers for hot page info.

Now if hot page promotion handler gets called first and if it promotes the page, calling LRU registered handler still makes sense? May be not I suppose.

On the other hand if LRU subsystem handler gets first and it adjusts/modifies the hot page's list, it would still make sense to activate the hot page promotion handler to check for possible promotion.

Is this how you are envisioning the different consumers of hot page access info could work/cooperate?

Regards,
Bharata.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux