mm/damon: introduce DAMOS filter type for unmapped pages

User decides whether their memory will be mapped or unmapped. It implies that the two types of memory can have different characteristics and management requirements. Provide the DAMON-observaibility DAMOS-operation capability for the different types by introducing a new DAMOS filter type for unmapped pages.

Changes from RFC
(https://lore.kernel.org/[email protected])
- Rebase on latest mm-unstable
- Wordsmith commit message
- Add documentation

SeongJae Park (2):
mm/damon: implement a new DAMOS filter type for unmapped pages Docs/mm/damon/design: document unmapped DAMOS filter type

 Documentation/mm/damon/design.rst | 2 ++
 include/linux/damon.h             | 2 ++
 mm/damon/paddr.c                  | 3 +++
 mm/damon/sysfs-schemes.c          | 1 +
 4 files changed, 8 insertions(+)

base-commit: a2130e89cbd08ddb6f023b0b10eb87ebbc67add1

2.39.5

Implement yet another DAMOS filter type for unmapped pages on DAMON kernel API, and add support of it from the physical address space DAMON operations set (paddr). Since it is for only unmapped pages, support from the virtual address spaces DAMON operations set (vaddr) is not required.

---
 include/linux/damon.h    | 2 ++
 mm/damon/paddr.c         | 3 +++
 mm/damon/sysfs-schemes.c | 1 +
 3 files changed, 6 insertions(+)

index 0ed84b3656fc..795ca09b1107 100644
@@ -337,6 +337,7 @@ struct damos_stat {
  * @DAMOS_FILTER_TYPE_MEMCG:	Specific memcg's pages.
  * @DAMOS_FILTER_TYPE_YOUNG:	Recently accessed pages.
  * @DAMOS_FILTER_TYPE_HUGEPAGE_SIZE:	Page is part of a hugepage.
+ * @DAMOS_FILTER_TYPE_UNMAPPED:	Unmapped pages.
  * @DAMOS_FILTER_TYPE_ADDR:	Address range.
  * @DAMOS_FILTER_TYPE_TARGET:	Data Access Monitoring target.
  * @NR_DAMOS_FILTER_TYPES:	Number of filter types.

@@ -357,6 +358,7 @@ enum damos_filter_type {
 	DAMOS_FILTER_TYPE_MEMCG,
 	DAMOS_FILTER_TYPE_YOUNG,
 	DAMOS_FILTER_TYPE_HUGEPAGE_SIZE,
+	DAMOS_FILTER_TYPE_UNMAPPED,
 	DAMOS_FILTER_TYPE_ADDR,
 	DAMOS_FILTER_TYPE_TARGET,
 	NR_DAMOS_FILTER_TYPES,

index 9f03e1980b8d..25090230da17 100644
@@ -236,6 +236,9 @@ static bool damos_pa_filter_match(struct damos_filter *filter,
 		matched = filter->sz_range.min <= folio_sz &&
 			  folio_sz <= filter->sz_range.max;
 		break;
+	case DAMOS_FILTER_TYPE_UNMAPPED:
+		matched = !folio_mapped(folio) || !folio_raw_mapping(folio);
+		break;
 	default:
 		break;
 	}

index 881d00bb3a34..66a1c46cee84 100644
@@ -331,6 +331,7 @@ static const char * const damon_sysfs_scheme_filter_type_strs[] = {
 	"memcg",
 	"young",
 	"hugepage_size",
+	"unmapped",
 	"addr",
 	"target",
 };

2.39.5

Document availability and meaning of unmapped DAMOS filter type on design document. Since introduction of the type requires no additional user ABI, usage and ABI document need no update.

---
 Documentation/mm/damon/design.rst | 2 ++
 1 file changed, 2 insertions(+)

index 6a66aa0833fd..5af991551a86 100644
@@ -617,6 +617,8 @@ Below ``type`` of filters are currently supported.
           scheme.
     - hugepage_size
         - Applied to pages that managed in a given size range.
+    - unmapped
+        - Applied to pages that unmapped.
 
 To know how user-space can set the filters via :ref:`DAMON sysfs interface
 <sysfs_interface>`, refer to :ref:`filters <sysfs_filters>` part of the

2.39.5

Hi SeongJae,

I asked it before at https://github.com/damonitor/damo/issues/13 about monitoring unused paddr area but I see this patch series is related to applying DAMOS action.

Regarding that, do you think we can skip those unused memory area using this filter before applying DAMOS action?

I'm not sure if the current DAMOS tries pageout/migrate action for those unused area because they are detected as cold area although those will be imediately skiped inside action scheme.

Thanks,
Honggyu

Hello Honggyu,

My understanding of "unused" memory that you mentioned is memory that not allocated for user data. This memory cannot get accessed by user, so DAMON treats this memory as always not accessed.

"unmapped" memory I'm saying about here is memory that not mapped to userspace. For example, unmapped pages in pge cache. This memory can be accessed, for eaxmple through page cache using read()/write() like system calls.

So I think this is not really related with the GitHub discussion. Please let me know if I'm missing something.

So, no.

This is the current behavior. DAMOS will try to do whatever action to whatever region if requested, see the action is not applicable to the page, and move on to the next page. Please note that filter-based page level skipping is not that different from the page level action applicability checking.

If you know where "unused" memory located, and you want to make DAMON/S entirely ignore it, you could use DAMON target address range, or address range type DAMOS filter. I'm not sure if this is what you're looking for, though.

My understanding of your concern about "unused" memory on the GitHub discussion was more about adaptive reions adjustment efficiency. I recently posted[1] some ideas to improve the mechanism. Any feedback about the idea will be welcomed and help prioritizing it.

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

[...]