2022-05-17 17:03:57

by Kirill A. Shutemov

Subject: [PATCHv6 15/15] mm/vmstat: Add counter for memory accepting

The counter increased every time kernel accepts a memory region.

The counter allows to see if memory acceptation is still ongoing and
contributes to memory allocation latency.

Signed-off-by: Kirill A. Shutemov <[email protected]>
---
arch/x86/mm/unaccepted_memory.c | 1 +
include/linux/vm_event_item.h | 3 +++
mm/vmstat.c | 3 +++
3 files changed, 7 insertions(+)

diff --git a/arch/x86/mm/unaccepted_memory.c b/arch/x86/mm/unaccepted_memory.c
index 6ecd79101922..fe1dabfae326 100644
--- a/arch/x86/mm/unaccepted_memory.c
+++ b/arch/x86/mm/unaccepted_memory.c
@@ -74,6 +74,7 @@ void accept_memory(phys_addr_t start, phys_addr_t end)
}

bitmap_clear(bitmap, range_start, len);
+ count_vm_events(ACCEPT_MEMORY, len * PMD_SIZE / PAGE_SIZE);

/* In early boot nr_unaccepted is not yet initialized */
if (nr_unaccepted) {
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index 16a0a4fd000b..6a468164a2f9 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -136,6 +136,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
#ifdef CONFIG_X86
DIRECT_MAP_LEVEL2_SPLIT,
DIRECT_MAP_LEVEL3_SPLIT,
+#endif
+#ifdef CONFIG_UNACCEPTED_MEMORY
+ ACCEPT_MEMORY,
#endif
NR_VM_EVENT_ITEMS
};
diff --git a/mm/vmstat.c b/mm/vmstat.c
index b75b1a64b54c..4c9197f32406 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1397,6 +1397,9 @@ const char * const vmstat_text[] = {
"direct_map_level2_splits",
"direct_map_level3_splits",
#endif
+#ifdef CONFIG_UNACCEPTED_MEMORY
+ "accept_memory",
+#endif
#endif /* CONFIG_VM_EVENT_COUNTERS || CONFIG_MEMCG */
};
#endif /* CONFIG_PROC_FS || CONFIG_SYSFS || CONFIG_NUMA || CONFIG_MEMCG */
--
2.35.1

2022-06-01 19:43:39

by David Hildenbrand

Subject: Re: [PATCHv6 15/15] mm/vmstat: Add counter for memory accepting

On 17.05.22 17:34, Kirill A. Shutemov wrote:
> The counter increased every time kernel accepts a memory region.
>
> The counter allows to see if memory acceptation is still ongoing and
> contributes to memory allocation latency.
>
> Signed-off-by: Kirill A. Shutemov <[email protected]>
> ---
> arch/x86/mm/unaccepted_memory.c | 1 +
> include/linux/vm_event_item.h | 3 +++
> mm/vmstat.c | 3 +++
> 3 files changed, 7 insertions(+)
>
> diff --git a/arch/x86/mm/unaccepted_memory.c b/arch/x86/mm/unaccepted_memory.c
> index 6ecd79101922..fe1dabfae326 100644
> --- a/arch/x86/mm/unaccepted_memory.c
> +++ b/arch/x86/mm/unaccepted_memory.c
> @@ -74,6 +74,7 @@ void accept_memory(phys_addr_t start, phys_addr_t end)
> }
>
> bitmap_clear(bitmap, range_start, len);
> + count_vm_events(ACCEPT_MEMORY, len * PMD_SIZE / PAGE_SIZE);
>

It's a bit weird that this is accounted from arch code. Also, I'm a bit
confused about the granularity here (PMD_SIZE).

> /* In early boot nr_unaccepted is not yet initialized */
> if (nr_unaccepted) {
> diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
> index 16a0a4fd000b..6a468164a2f9 100644
> --- a/include/linux/vm_event_item.h
> +++ b/include/linux/vm_event_item.h
> @@ -136,6 +136,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
> #ifdef CONFIG_X86
> DIRECT_MAP_LEVEL2_SPLIT,
> DIRECT_MAP_LEVEL3_SPLIT,
> +#endif
> +#ifdef CONFIG_UNACCEPTED_MEMORY
> + ACCEPT_MEMORY,
> #endif
> NR_VM_EVENT_ITEMS
> };
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index b75b1a64b54c..4c9197f32406 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -1397,6 +1397,9 @@ const char * const vmstat_text[] = {
> "direct_map_level2_splits",
> "direct_map_level3_splits",
> #endif
> +#ifdef CONFIG_UNACCEPTED_MEMORY
> + "accept_memory",
> +#endif
> #endif /* CONFIG_VM_EVENT_COUNTERS || CONFIG_MEMCG */
> };
> #endif /* CONFIG_PROC_FS || CONFIG_SYSFS || CONFIG_NUMA || CONFIG_MEMCG */

How exactly would I be able to figure out if "memory acceptation is
still ongoing" if there is one last remaining page stuck at the tail of
the freelist?

Wouldn't it make more sense to actually count the number of unaccepted
pages in the buddy? Once that number drops to 0, one knows that there is
no unaccepted memory left in the buddy.

--
Thanks,

David / dhildenb

2022-06-01 21:14:21

by Kirill A. Shutemov

Subject: Re: [PATCHv6 15/15] mm/vmstat: Add counter for memory accepting

On Wed, Jun 01, 2022 at 11:05:40AM +0200, David Hildenbrand wrote:
> On 17.05.22 17:34, Kirill A. Shutemov wrote:
> > The counter increased every time kernel accepts a memory region.
> >
> > The counter allows to see if memory acceptation is still ongoing and
> > contributes to memory allocation latency.
> >
> > Signed-off-by: Kirill A. Shutemov <[email protected]>
> > ---
> > arch/x86/mm/unaccepted_memory.c | 1 +
> > include/linux/vm_event_item.h | 3 +++
> > mm/vmstat.c | 3 +++
> > 3 files changed, 7 insertions(+)
> >
> > diff --git a/arch/x86/mm/unaccepted_memory.c b/arch/x86/mm/unaccepted_memory.c
> > index 6ecd79101922..fe1dabfae326 100644
> > --- a/arch/x86/mm/unaccepted_memory.c
> > +++ b/arch/x86/mm/unaccepted_memory.c
> > @@ -74,6 +74,7 @@ void accept_memory(phys_addr_t start, phys_addr_t end)
> > }
> >
> > bitmap_clear(bitmap, range_start, len);
> > + count_vm_events(ACCEPT_MEMORY, len * PMD_SIZE / PAGE_SIZE);
> >
>
> It's a bit weird that this is accounted from arch code

That's very serialization happens.

We can do it in the core mm if we can tolerate sporious vmcount bump.
Otherwise it has to happen under the lock in the arch code.

> Also, I'm a bit
> confused about the granularity here (PMD_SIZE).

That's how we track it in x86. The count itself is in pages. Different
arch can choose different granularity.

> > /* In early boot nr_unaccepted is not yet initialized */
> > if (nr_unaccepted) {
> > diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
> > index 16a0a4fd000b..6a468164a2f9 100644
> > --- a/include/linux/vm_event_item.h
> > +++ b/include/linux/vm_event_item.h
> > @@ -136,6 +136,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
> > #ifdef CONFIG_X86
> > DIRECT_MAP_LEVEL2_SPLIT,
> > DIRECT_MAP_LEVEL3_SPLIT,
> > +#endif
> > +#ifdef CONFIG_UNACCEPTED_MEMORY
> > + ACCEPT_MEMORY,
> > #endif
> > NR_VM_EVENT_ITEMS
> > };
> > diff --git a/mm/vmstat.c b/mm/vmstat.c
> > index b75b1a64b54c..4c9197f32406 100644
> > --- a/mm/vmstat.c
> > +++ b/mm/vmstat.c
> > @@ -1397,6 +1397,9 @@ const char * const vmstat_text[] = {
> > "direct_map_level2_splits",
> > "direct_map_level3_splits",
> > #endif
> > +#ifdef CONFIG_UNACCEPTED_MEMORY
> > + "accept_memory",
> > +#endif
> > #endif /* CONFIG_VM_EVENT_COUNTERS || CONFIG_MEMCG */
> > };
> > #endif /* CONFIG_PROC_FS || CONFIG_SYSFS || CONFIG_NUMA || CONFIG_MEMCG */
>
> How exactly would I be able to figure out if "memory acceptation is
> still ongoing" if there is one last remaining page stuck at the tail of
> the freelist?

"still ongoing" in sense it is happening now, like if it increases system
does memory accept.

> Wouldn't it make more sense to actually count the number of unaccepted
> pages in the buddy? Once that number drops to 0, one knows that there is
> no unaccepted memory left in the buddy.

Patch 10/15 does this, but not in buddy.

--
Kirill A. Shutemov