[RFC PATCH bpf-next 0/9] mm, bpf: Add BPF into /proc/meminfo

* [RFC PATCH bpf-next 0/9] mm, bpf: Add BPF into /proc/meminfo
@ 2022-12-12  0:37 Yafang Shao
  2022-12-12  0:37 ` [RFC PATCH bpf-next 1/9] mm: Introduce active vm item Yafang Shao
                   ` (9 more replies)
  0 siblings, 10 replies; 23+ messages in thread
From: Yafang Shao @ 2022-12-12  0:37 UTC (permalink / raw)
  To: ast, daniel, andrii, kafai, songliubraving, yhs, john.fastabend,
	kpsingh, sdf, haoluo, jolsa, tj, dennis, cl, akpm, penberg,
	rientjes, iamjoonsoo.kim, vbabka, roman.gushchin, 42.hyeyoo
  Cc: linux-mm, bpf, Yafang Shao

Currently there's no way to get BPF memory usage, while we can only
estimate the usage by bpftool or memcg, both of which are not reliable.

- bpftool
  `bpftool {map,prog} show` can show us the memlock of each map and
  prog, but the memlock is vary from the real memory size. The memlock
  of a bpf object is approximately
  `round_up(key_size + value_size, 8) * max_entries`,
  so 1) it can't apply to the non-preallocated bpf map which may
  increase or decrease the real memory size dynamically. 2) the element
  size of some bpf map is not `key_size + value_size`, for example the
  element size of htab is
  `sizeof(struct htab_elem) + round_up(key_size, 8) + round_up(value_size, 8)`
  That said the differece between these two values may be very great if
  the key_size and value_size is small. For example in my verifaction,
  the size of memlock and real memory of a preallocated hash map are,

  $ grep BPF /proc/meminfo
  BPF:             1026048 B <<< the size of preallocated memalloc pool

  (create hash map)

  $ bpftool map show
  3: hash  name count_map  flags 0x0
          key 4B  value 4B  max_entries 1048576  memlock 8388608B

  $ grep BPF /proc/meminfo
  BPF:            84919344 B

  So the real memory size is $((84919344 - 1026048)) which is 83893296
  bytes while the memlock is only 8388608 bytes.

- memcg  
  With memcg we only know that the BPF memory usage is less than
  memory.usage_in_bytes (or memory.current in v2). Furthermore, we only 
  know that the BPF memory usage is less than $MemTotal if the BPF
  object is charged into root memcg :)

So we need a way to get the BPF memory usage especially there will be
more and more bpf programs running on the production environment. The
memory usage of BPF memory is not trivial, which deserves a new item in
/proc/meminfo.

This patchset introduce a solution to calculate the BPF memory usage.
This solution is similar to how memory is charged into memcg, so it is
easy to understand. It counts three types of memory usage -
 - page
   via kmalloc, vmalloc, kmem_cache_alloc or alloc pages directly and
   their families.
   When a page is allocated, we will count its size and mark the head
   page, and then check the head page at page freeing.
 - slab
   via kmalloc, kmem_cache_alloc and their families.
   When a slab object is allocated, we will mark this object in this
   slab and check it at slab object freeing. That said we need extra memory
   to store the information of each object in a slab.
 - percpu 
   via alloc_percpu and its family.
   When a percpu area is allocated, we will mark this area in this
   percpu chunk and check it at percpu area freeing. That said we need
   extra memory to store the information of each area in a percpu chunk.

So we only need to annotate the allcation to add the BPF memory size,
and the sub of the BPF memory size will be handled automatically at
freeing. We can annotate it in irq, softirq or process context. To avoid
counting the nested allcations, for example the percpu backing allocator,
we reuse the __GFP_ACCOUNT to filter them out. __GFP_ACCOUNT also make
the count consistent with memcg accounting. 

To store the information of a slab or a page, we need to create a new
member in struct page, but we can do it in page extension which can
avoid changing the size of struct page. So a new page extension
active_vm is introduced. Each page and each slab which is allocated as
BPF memory will have a struct active_vm. The reason it is named as
active_vm is that we can extend it to other areas easily, for example in
the future we may use it to count other memory usage. 

The new page extension active_vm can be disabled via CONFIG_ACTIVE_VM at
compile time or kernel parameter `active_vm=` at runtime.

Below is the result of this patchset,

$ grep BPF /proc/meminfo
BPF:                1002 kB

Currently only bpf map is supported, and only slub in supported.

Future works:
- support bpf prog
- not sure if it needs to support slab
  (it seems slab will be deprecated)
- support per-map memory usage
- support per-memcg memory usage

Yafang Shao (9):
  mm: Introduce active vm item
  mm: Allow using active vm in all contexts
  mm: percpu: Account active vm for percpu
  mm: slab: Account active vm for slab
  mm: Account active vm for page
  bpf: Introduce new helpers bpf_ringbuf_pages_{alloc,free}
  bpf: Use bpf_map_kzalloc in arraymap
  bpf: Use bpf_map_kvcalloc in bpf_local_storage
  bpf: Use active vm to account bpf map memory usage

 fs/proc/meminfo.c              |   3 +
 include/linux/active_vm.h      |  73 ++++++++++++
 include/linux/bpf.h            |   8 ++
 include/linux/page_ext.h       |   1 +
 include/linux/sched.h          |   5 +
 kernel/bpf/arraymap.c          |  16 +--
 kernel/bpf/bpf_local_storage.c |   4 +-
 kernel/bpf/memalloc.c          |   5 +
 kernel/bpf/ringbuf.c           |  75 ++++++++----
 kernel/bpf/syscall.c           |  40 ++++++-
 kernel/fork.c                  |   4 +
 mm/Kconfig                     |   8 ++
 mm/Makefile                    |   1 +
 mm/active_vm.c                 | 203 +++++++++++++++++++++++++++++++++
 mm/active_vm.h                 |  74 ++++++++++++
 mm/page_alloc.c                |  14 +++
 mm/page_ext.c                  |   4 +
 mm/percpu-internal.h           |   3 +
 mm/percpu.c                    |  43 +++++++
 mm/slab.h                      |   7 ++
 mm/slub.c                      |   2 +
 21 files changed, 557 insertions(+), 36 deletions(-)
 create mode 100644 include/linux/active_vm.h
 create mode 100644 mm/active_vm.c
 create mode 100644 mm/active_vm.h

-- 
2.30.1 (Apple Git-130)

^ permalink raw reply	[flat|nested] 23+ messages in thread