Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Christoph Hellwig]

I'd suggest you discuss you needs with the slab mainainers and the mm
community firs.

On Wed, Jun 22, 2022 at 05:32:25PM -0700, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
> 
> Introduce any context BPF specific memory allocator.
> 
> Tracing BPF programs can attach to kprobe and fentry. Hence they
> run in unknown context where calling plain kmalloc() might not be safe.
> Front-end kmalloc() with per-cpu per-bucket cache of free elements.
> Refill this cache asynchronously from irq_work.
> 
> There is a lot more work ahead, but this set is useful base.
> Future work:
> - get rid of call_rcu in hash map
> - get rid of atomic_inc/dec in hash map
> - tune watermarks per allocation size
> - adopt this approach alloc_percpu_gfp
> - expose bpf_mem_alloc as uapi FD to be used in dynptr_alloc, kptr_alloc
> - add sysctl to force bpf_mem_alloc in hash map when safe even if pre-alloc
>   requested to reduce memory consumption
> - convert lru map to bpf_mem_alloc
> 
> Alexei Starovoitov (5):
>   bpf: Introduce any context BPF specific memory allocator.
>   bpf: Convert hash map to bpf_mem_alloc.
>   selftests/bpf: Improve test coverage of test_maps
>   samples/bpf: Reduce syscall overhead in map_perf_test.
>   bpf: Relax the requirement to use preallocated hash maps in tracing
>     progs.
> 
>  include/linux/bpf_mem_alloc.h           |  26 ++
>  kernel/bpf/Makefile                     |   2 +-
>  kernel/bpf/hashtab.c                    |  16 +-
>  kernel/bpf/memalloc.c                   | 512 ++++++++++++++++++++++++
>  kernel/bpf/verifier.c                   |  31 +-
>  samples/bpf/map_perf_test_kern.c        |  22 +-
>  tools/testing/selftests/bpf/test_maps.c |  38 +-
>  7 files changed, 610 insertions(+), 37 deletions(-)
>  create mode 100644 include/linux/bpf_mem_alloc.h
>  create mode 100644 kernel/bpf/memalloc.c
> 
> -- 
> 2.30.2
> 
---end quoted text---

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Christoph Lameter]

> From: Alexei Starovoitov <ast@kernel.org>
>
> Introduce any context BPF specific memory allocator.
>
> Tracing BPF programs can attach to kprobe and fentry. Hence they
> run in unknown context where calling plain kmalloc() might not be safe.
> Front-end kmalloc() with per-cpu per-bucket cache of free elements.
> Refill this cache asynchronously from irq_work.

GFP_ATOMIC etc is not going to work for you?

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Mon, Jun 27, 2022 at 5:17 PM Christoph Lameter <cl@gentwo.de> wrote:
>
> > From: Alexei Starovoitov <ast@kernel.org>
> >
> > Introduce any context BPF specific memory allocator.
> >
> > Tracing BPF programs can attach to kprobe and fentry. Hence they
> > run in unknown context where calling plain kmalloc() might not be safe.
> > Front-end kmalloc() with per-cpu per-bucket cache of free elements.
> > Refill this cache asynchronously from irq_work.
>
> GFP_ATOMIC etc is not going to work for you?

slab_alloc_node->slab_alloc->local_lock_irqsave
kprobe -> bpf prog -> slab_alloc_node -> deadlock.
In other words, the slow path of slab allocator takes locks.
Which makes it unsafe to use from tracing bpf progs.
That's why we preallocated all elements in bpf maps,
so there are no calls to mm or rcu logic.
bpf specific allocator cannot use locks at all.
try_lock approach could have been used in alloc path,
but free path cannot fail with try_lock.
Hence the algorithm in this patch is purely lockless.
bpf prog can attach to spin_unlock_irqrestore and
safely do bpf_mem_alloc.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Christoph Lameter]

On Mon, 27 Jun 2022, Alexei Starovoitov wrote:

> On Mon, Jun 27, 2022 at 5:17 PM Christoph Lameter <cl@gentwo.de> wrote:
> >
> > > From: Alexei Starovoitov <ast@kernel.org>
> > >
> > > Introduce any context BPF specific memory allocator.
> > >
> > > Tracing BPF programs can attach to kprobe and fentry. Hence they
> > > run in unknown context where calling plain kmalloc() might not be safe.
> > > Front-end kmalloc() with per-cpu per-bucket cache of free elements.
> > > Refill this cache asynchronously from irq_work.
> >
> > GFP_ATOMIC etc is not going to work for you?
>
> slab_alloc_node->slab_alloc->local_lock_irqsave
> kprobe -> bpf prog -> slab_alloc_node -> deadlock.
> In other words, the slow path of slab allocator takes locks.

That is a relatively new feature due to RT logic support. without RT this
would be a simple irq disable.

Generally doing slab allocation  while debugging slab allocation is not
something that can work. Can we exempt RT locks/irqsave or slab alloc from
BPF tracing?

I would assume that other key items of kernel logic will have similar
issues.

> Which makes it unsafe to use from tracing bpf progs.
> That's why we preallocated all elements in bpf maps,
> so there are no calls to mm or rcu logic.
> bpf specific allocator cannot use locks at all.
> try_lock approach could have been used in alloc path,
> but free path cannot fail with try_lock.
> Hence the algorithm in this patch is purely lockless.
> bpf prog can attach to spin_unlock_irqrestore and
> safely do bpf_mem_alloc.

That is generally safe unless you get into reetrance issues with memory
allocation.

Which begs the question:

What happens if I try to use BPF to trace *your* shiny new memory
allocation functions in the BPF logic like bpf_mem_alloc? How do you stop
that from happening?

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Tue, Jun 28, 2022 at 03:57:54PM +0200, Christoph Lameter wrote:
> On Mon, 27 Jun 2022, Alexei Starovoitov wrote:
> 
> > On Mon, Jun 27, 2022 at 5:17 PM Christoph Lameter <cl@gentwo.de> wrote:
> > >
> > > > From: Alexei Starovoitov <ast@kernel.org>
> > > >
> > > > Introduce any context BPF specific memory allocator.
> > > >
> > > > Tracing BPF programs can attach to kprobe and fentry. Hence they
> > > > run in unknown context where calling plain kmalloc() might not be safe.
> > > > Front-end kmalloc() with per-cpu per-bucket cache of free elements.
> > > > Refill this cache asynchronously from irq_work.
> > >
> > > GFP_ATOMIC etc is not going to work for you?
> >
> > slab_alloc_node->slab_alloc->local_lock_irqsave
> > kprobe -> bpf prog -> slab_alloc_node -> deadlock.
> > In other words, the slow path of slab allocator takes locks.
> 
> That is a relatively new feature due to RT logic support. without RT this
> would be a simple irq disable.

Not just RT.
It's a slow path:
        if (IS_ENABLED(CONFIG_PREEMPT_RT) ||
            unlikely(!object || !slab || !node_match(slab, node))) {
              local_unlock_irqrestore(&s->cpu_slab->lock,...);
and that's not the only lock in there.
new_slab->allocate_slab... alloc_pages grabbing more locks.

> Generally doing slab allocation  while debugging slab allocation is not
> something that can work. Can we exempt RT locks/irqsave or slab alloc from
> BPF tracing?

People started doing lock profiling with bpf back in 2017.
People do rcu profiling now and attaching bpf progs to all kinds of low level
kernel internals: page alloc, etc.

> I would assume that other key items of kernel logic will have similar
> issues.

We're _not_ asking for any changes from mm/slab side.
Things were working all these years. We're making them more efficient now
by getting rid of 'lets prealloc everything' approach.

> > Which makes it unsafe to use from tracing bpf progs.
> > That's why we preallocated all elements in bpf maps,
> > so there are no calls to mm or rcu logic.
> > bpf specific allocator cannot use locks at all.
> > try_lock approach could have been used in alloc path,
> > but free path cannot fail with try_lock.
> > Hence the algorithm in this patch is purely lockless.
> > bpf prog can attach to spin_unlock_irqrestore and
> > safely do bpf_mem_alloc.
> 
> That is generally safe unless you get into reetrance issues with memory
> allocation.

Right. Generic slab/mm/page_alloc/rcu are not ready for reentrance and
are not safe from NMI either.
That's why we're added all kinds of safey mechanisms in bpf layers.

> Which begs the question:
> 
> What happens if I try to use BPF to trace *your* shiny new memory

'shiny and new' is overstatement. It's a trivial lock less freelist layer
on top of kmalloc. Please read the patch.

> allocation functions in the BPF logic like bpf_mem_alloc? How do you stop
> that from happening?

here is the comment in the patch:
/* notrace is necessary here and in other functions to make sure
 * bpf programs cannot attach to them and cause llist corruptions.
 */

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Christoph Lameter]

On Tue, 28 Jun 2022, Alexei Starovoitov wrote:

> > That is a relatively new feature due to RT logic support. without RT this
> > would be a simple irq disable.
>
> Not just RT.
> It's a slow path:
>         if (IS_ENABLED(CONFIG_PREEMPT_RT) ||
>             unlikely(!object || !slab || !node_match(slab, node))) {
>               local_unlock_irqrestore(&s->cpu_slab->lock,...);
> and that's not the only lock in there.
> new_slab->allocate_slab... alloc_pages grabbing more locks.


Its not a lock for !RT.

The fastpath is lockless if hardware allows that but then we go into more
and more serialiation needs as the allocation gets more into the page
allocator logic.

> > allocation functions in the BPF logic like bpf_mem_alloc? How do you stop
> > that from happening?
>
> here is the comment in the patch:
> /* notrace is necessary here and in other functions to make sure
>  * bpf programs cannot attach to them and cause llist corruptions.
>  */

"notrace".... Ok Hmmm...

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Tue, Jun 28, 2022 at 7:35 PM Christoph Lameter <cl@gentwo.de> wrote:
>
> On Tue, 28 Jun 2022, Alexei Starovoitov wrote:
>
> > > That is a relatively new feature due to RT logic support. without RT this
> > > would be a simple irq disable.
> >
> > Not just RT.
> > It's a slow path:
> >         if (IS_ENABLED(CONFIG_PREEMPT_RT) ||
> >             unlikely(!object || !slab || !node_match(slab, node))) {
> >               local_unlock_irqrestore(&s->cpu_slab->lock,...);
> > and that's not the only lock in there.
> > new_slab->allocate_slab... alloc_pages grabbing more locks.
>
>
> Its not a lock for !RT.
>
> The fastpath is lockless if hardware allows that but then we go into more
> and more serialiation needs as the allocation gets more into the page
> allocator logic.

On RT fast path == slow path with a lock.
On !RT fast path is lock less.
That's all correct.
bpf side has to make sure safety in all possible paths
therefore RT or !RT makes no difference.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Vlastimil Babka]

On 6/29/22 04:49, Alexei Starovoitov wrote:
> On Tue, Jun 28, 2022 at 7:35 PM Christoph Lameter <cl@gentwo.de> wrote:
>>
>> On Tue, 28 Jun 2022, Alexei Starovoitov wrote:
>>
>> > > That is a relatively new feature due to RT logic support. without RT this
>> > > would be a simple irq disable.
>> >
>> > Not just RT.
>> > It's a slow path:
>> >         if (IS_ENABLED(CONFIG_PREEMPT_RT) ||
>> >             unlikely(!object || !slab || !node_match(slab, node))) {
>> >               local_unlock_irqrestore(&s->cpu_slab->lock,...);
>> > and that's not the only lock in there.
>> > new_slab->allocate_slab... alloc_pages grabbing more locks.
>>
>>
>> Its not a lock for !RT.
>>
>> The fastpath is lockless if hardware allows that but then we go into more
>> and more serialiation needs as the allocation gets more into the page
>> allocator logic.

Yeah I don't think the recent RT-related changes made this much worse than
it already was. In alloc side you could perhaps try the really lockless
fastpaths only and fail if e.g. the per-cpu slabs were empty (but would BPF
be happy with that?). On the free side though you could end up having to
move a slab from partial to free list as a result, and now a spin lock is
needed (even before the RT changes), and you can't really fail a free...

> On RT fast path == slow path with a lock.
> On !RT fast path is lock less.
> That's all correct.
> bpf side has to make sure safety in all possible paths
> therefore RT or !RT makes no difference.

So AFAIK we don't right now have what BFP needs - an extra-constrained kind
of GFP_ATOMIC. I don't object you adding it privately. But it's another
reason to think about if these things can be generalized. For example we had
a discussion about the Maple tree having kinda similar kinds of requirements
to avoid its tree node preallocations always for the worst possible case.

I'm not sure we can sanely implement this within each of SLAB/SLUB/SLOB, or
rather provide a generic cache on top...

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Mon, Jul 04, 2022 at 06:13:17PM +0200, Vlastimil Babka wrote:
> On 6/29/22 04:49, Alexei Starovoitov wrote:
> > On Tue, Jun 28, 2022 at 7:35 PM Christoph Lameter <cl@gentwo.de> wrote:
> >>
> >> On Tue, 28 Jun 2022, Alexei Starovoitov wrote:
> >>
> >> > > That is a relatively new feature due to RT logic support. without RT this
> >> > > would be a simple irq disable.
> >> >
> >> > Not just RT.
> >> > It's a slow path:
> >> >         if (IS_ENABLED(CONFIG_PREEMPT_RT) ||
> >> >             unlikely(!object || !slab || !node_match(slab, node))) {
> >> >               local_unlock_irqrestore(&s->cpu_slab->lock,...);
> >> > and that's not the only lock in there.
> >> > new_slab->allocate_slab... alloc_pages grabbing more locks.
> >>
> >>
> >> Its not a lock for !RT.
> >>
> >> The fastpath is lockless if hardware allows that but then we go into more
> >> and more serialiation needs as the allocation gets more into the page
> >> allocator logic.
> 
> Yeah I don't think the recent RT-related changes made this much worse than
> it already was. In alloc side you could perhaps try the really lockless
> fastpaths only and fail if e.g. the per-cpu slabs were empty (but would BPF
> be happy with that?). On the free side though you could end up having to
> move a slab from partial to free list as a result, and now a spin lock is
> needed (even before the RT changes), and you can't really fail a free...
> 
> > On RT fast path == slow path with a lock.
> > On !RT fast path is lock less.
> > That's all correct.
> > bpf side has to make sure safety in all possible paths
> > therefore RT or !RT makes no difference.
> 
> So AFAIK we don't right now have what BFP needs - an extra-constrained kind
> of GFP_ATOMIC. I don't object you adding it privately. But it's another
> reason to think about if these things can be generalized. For example we had
> a discussion about the Maple tree having kinda similar kinds of requirements
> to avoid its tree node preallocations always for the worst possible case.

What kind of maple tree needs? Does it need to be fully reentrant and nmi safe?
Not really. The caller knows the context and can choose appropriate flags.
While bpf alloc doesn't know the context. The bpf prog can be called from
places where slab/page/kasan specific locks are held which makes all these
pieces non-reentrable.
The full prealloc of bpf maps (read: waste a lot of memory) was our solution until now.
This is specific to tracing bpf programs, of course.
bpf networking, bpf security, sleepable bpf are completely different.

> I'm not sure we can sanely implement this within each of SLAB/SLUB/SLOB, or
> rather provide a generic cache on top...

Notice that all of bpf cache functions are notrace/nokprobe/no locks.
The main difference vs all other allocators is bpf_mem_alloc from cache
and refill of the cache are two asynchronous operations. It allows the former
to be reentrant and nmi safe.
All in tree allocators sooner or later synchornously call into page_alloc,
kasan, memleak and other debugging facilites that grab locks.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Vlastimil Babka]

On 7/6/22 19:43, Alexei Starovoitov wrote:
> On Mon, Jul 04, 2022 at 06:13:17PM +0200, Vlastimil Babka wrote:
>> 
>> > On RT fast path == slow path with a lock.
>> > On !RT fast path is lock less.
>> > That's all correct.
>> > bpf side has to make sure safety in all possible paths
>> > therefore RT or !RT makes no difference.
>> 
>> So AFAIK we don't right now have what BFP needs - an extra-constrained kind
>> of GFP_ATOMIC. I don't object you adding it privately. But it's another
>> reason to think about if these things can be generalized. For example we had
>> a discussion about the Maple tree having kinda similar kinds of requirements
>> to avoid its tree node preallocations always for the worst possible case.
> 
> What kind of maple tree needs? Does it need to be fully reentrant and nmi safe?
> Not really. The caller knows the context and can choose appropriate flags.
> While bpf alloc doesn't know the context. The bpf prog can be called from
> places where slab/page/kasan specific locks are held which makes all these
> pieces non-reentrable.

Sure, the context restrictions can differ between bpf, maple tree and other
users, but I think there's common need not to be dependend on slab/page
allocator implementation internals and its locking. So the common
allocator/cache on top would need to be implemented in a way to support the
most restricted context (e.g. bpf), thus be lockless and whatnot.
But then the individual users would be able to specify different details such as
- how much to preallocate in order to not run out of the cache
- what is allowed if we run out of cache - only async refill (bpf?) or also
e.g. GFP_NOWAIT for less restricted users?

> The full prealloc of bpf maps (read: waste a lot of memory) was our solution until now.
> This is specific to tracing bpf programs, of course.
> bpf networking, bpf security, sleepable bpf are completely different.
> 
>> I'm not sure we can sanely implement this within each of SLAB/SLUB/SLOB, or
>> rather provide a generic cache on top...
> 
> Notice that all of bpf cache functions are notrace/nokprobe/no locks.
> The main difference vs all other allocators is bpf_mem_alloc from cache
> and refill of the cache are two asynchronous operations. It allows the former
> to be reentrant and nmi safe.
> All in tree allocators sooner or later synchornously call into page_alloc,
> kasan, memleak and other debugging facilites that grab locks.
> 

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Matthew Wilcox]

On Mon, Jun 27, 2022 at 12:03:08AM -0700, Christoph Hellwig wrote:
> I'd suggest you discuss you needs with the slab mainainers and the mm
> community firs.
> 
> On Wed, Jun 22, 2022 at 05:32:25PM -0700, Alexei Starovoitov wrote:
> > From: Alexei Starovoitov <ast@kernel.org>
> > 
> > Introduce any context BPF specific memory allocator.
> > 
> > Tracing BPF programs can attach to kprobe and fentry. Hence they
> > run in unknown context where calling plain kmalloc() might not be safe.
> > Front-end kmalloc() with per-cpu per-bucket cache of free elements.
> > Refill this cache asynchronously from irq_work.

I can't tell from your description whether a bump allocator would work
for you.  That is, can you tell which allocations need to persist past
program execution (and use kmalloc for them) and which can be freed as
soon as the program has finished (and can use the bump allocator)?

If so, we already have one for you, the page_frag allocator
(Documentation/vm/page_frags.rst).  It might need to be extended to meet
your needs, but it's certainly faster than the kmalloc allocator.

> > There is a lot more work ahead, but this set is useful base.
> > Future work:
> > - get rid of call_rcu in hash map
> > - get rid of atomic_inc/dec in hash map
> > - tune watermarks per allocation size
> > - adopt this approach alloc_percpu_gfp
> > - expose bpf_mem_alloc as uapi FD to be used in dynptr_alloc, kptr_alloc
> > - add sysctl to force bpf_mem_alloc in hash map when safe even if pre-alloc
> >   requested to reduce memory consumption
> > - convert lru map to bpf_mem_alloc
> > 
> > Alexei Starovoitov (5):
> >   bpf: Introduce any context BPF specific memory allocator.
> >   bpf: Convert hash map to bpf_mem_alloc.
> >   selftests/bpf: Improve test coverage of test_maps
> >   samples/bpf: Reduce syscall overhead in map_perf_test.
> >   bpf: Relax the requirement to use preallocated hash maps in tracing
> >     progs.
> > 
> >  include/linux/bpf_mem_alloc.h           |  26 ++
> >  kernel/bpf/Makefile                     |   2 +-
> >  kernel/bpf/hashtab.c                    |  16 +-
> >  kernel/bpf/memalloc.c                   | 512 ++++++++++++++++++++++++
> >  kernel/bpf/verifier.c                   |  31 +-
> >  samples/bpf/map_perf_test_kern.c        |  22 +-
> >  tools/testing/selftests/bpf/test_maps.c |  38 +-
> >  7 files changed, 610 insertions(+), 37 deletions(-)
> >  create mode 100644 include/linux/bpf_mem_alloc.h
> >  create mode 100644 kernel/bpf/memalloc.c
> > 
> > -- 
> > 2.30.2
> > 
> ---end quoted text---
> 

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Mon, Jul 04, 2022 at 09:34:23PM +0100, Matthew Wilcox wrote:
> On Mon, Jun 27, 2022 at 12:03:08AM -0700, Christoph Hellwig wrote:
> > I'd suggest you discuss you needs with the slab mainainers and the mm
> > community firs.
> > 
> > On Wed, Jun 22, 2022 at 05:32:25PM -0700, Alexei Starovoitov wrote:
> > > From: Alexei Starovoitov <ast@kernel.org>
> > > 
> > > Introduce any context BPF specific memory allocator.
> > > 
> > > Tracing BPF programs can attach to kprobe and fentry. Hence they
> > > run in unknown context where calling plain kmalloc() might not be safe.
> > > Front-end kmalloc() with per-cpu per-bucket cache of free elements.
> > > Refill this cache asynchronously from irq_work.
> 
> I can't tell from your description whether a bump allocator would work
> for you.  That is, can you tell which allocations need to persist past
> program execution (and use kmalloc for them) and which can be freed as
> soon as the program has finished (and can use the bump allocator)?
> 
> If so, we already have one for you, the page_frag allocator
> (Documentation/vm/page_frags.rst).  It might need to be extended to meet
> your needs, but it's certainly faster than the kmalloc allocator.

Already looked at it, and into mempool, and everything we could find.
All 'normal' allocators sooner or later synchornously call into page_alloc,
kasan, memleak and other debugging facilites that grab locks which
make them unusable for bpf tracing progs.
The main difference of bpf specific alloc vs the rest is bpf_mem_alloc from
the cache and refill of the cache are two asynchronous operations.
It allows the former to be reentrant and nmi safe.

The speed of bpf mem alloc is secondary here.
The lock less free list is there to absorb async refill.
irq_work_queue is not instant while bpf prog might do several bpf_mem_alloc
before irq_work has a chance to refill.
We're thinking about self adjusting low/high watermarks that will be tunned by
the bpf verifier that has visibility into what program is going to do.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Matthew Wilcox]

On Wed, Jul 06, 2022 at 10:50:34AM -0700, Alexei Starovoitov wrote:
> On Mon, Jul 04, 2022 at 09:34:23PM +0100, Matthew Wilcox wrote:
> > On Mon, Jun 27, 2022 at 12:03:08AM -0700, Christoph Hellwig wrote:
> > > I'd suggest you discuss you needs with the slab mainainers and the mm
> > > community firs.
> > > 
> > > On Wed, Jun 22, 2022 at 05:32:25PM -0700, Alexei Starovoitov wrote:
> > > > From: Alexei Starovoitov <ast@kernel.org>
> > > > 
> > > > Introduce any context BPF specific memory allocator.
> > > > 
> > > > Tracing BPF programs can attach to kprobe and fentry. Hence they
> > > > run in unknown context where calling plain kmalloc() might not be safe.
> > > > Front-end kmalloc() with per-cpu per-bucket cache of free elements.
> > > > Refill this cache asynchronously from irq_work.
> > 
> > I can't tell from your description whether a bump allocator would work
> > for you.  That is, can you tell which allocations need to persist past
> > program execution (and use kmalloc for them) and which can be freed as
> > soon as the program has finished (and can use the bump allocator)?
> > 
> > If so, we already have one for you, the page_frag allocator
> > (Documentation/vm/page_frags.rst).  It might need to be extended to meet
> > your needs, but it's certainly faster than the kmalloc allocator.
> 
> Already looked at it, and into mempool, and everything we could find.
> All 'normal' allocators sooner or later synchornously call into page_alloc,

Today it does, yes.  But it might be adaptable to your needs if only I
knew what those needs were.  For example, I assume that a BPF program
has a fairly tight limit on how much memory it can cause to be allocated.
Right?

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> On Wed, Jul 06, 2022 at 10:50:34AM -0700, Alexei Starovoitov wrote:
> > On Mon, Jul 04, 2022 at 09:34:23PM +0100, Matthew Wilcox wrote:
> > > On Mon, Jun 27, 2022 at 12:03:08AM -0700, Christoph Hellwig wrote:
> > > > I'd suggest you discuss you needs with the slab mainainers and the mm
> > > > community firs.
> > > > 
> > > > On Wed, Jun 22, 2022 at 05:32:25PM -0700, Alexei Starovoitov wrote:
> > > > > From: Alexei Starovoitov <ast@kernel.org>
> > > > > 
> > > > > Introduce any context BPF specific memory allocator.
> > > > > 
> > > > > Tracing BPF programs can attach to kprobe and fentry. Hence they
> > > > > run in unknown context where calling plain kmalloc() might not be safe.
> > > > > Front-end kmalloc() with per-cpu per-bucket cache of free elements.
> > > > > Refill this cache asynchronously from irq_work.
> > > 
> > > I can't tell from your description whether a bump allocator would work
> > > for you.  That is, can you tell which allocations need to persist past
> > > program execution (and use kmalloc for them) and which can be freed as
> > > soon as the program has finished (and can use the bump allocator)?
> > > 
> > > If so, we already have one for you, the page_frag allocator
> > > (Documentation/vm/page_frags.rst).  It might need to be extended to meet
> > > your needs, but it's certainly faster than the kmalloc allocator.
> > 
> > Already looked at it, and into mempool, and everything we could find.
> > All 'normal' allocators sooner or later synchornously call into page_alloc,
> 
> Today it does, yes.  But it might be adaptable to your needs if only I
> knew what those needs were.  

needs: fully reentrant, nmi safe, any context safe.
I feel you're still failing to grasp 'any context' part.
bpf prog can attach to all available_filter_functions and should be able
to alloc from there.
Or kprobe anywhere and everywhere in the kernel .text that is not marked notrace/nokprobe.

> For example, I assume that a BPF program
> has a fairly tight limit on how much memory it can cause to be allocated.
> Right?

No. It's constrained by memcg limits only. It can allocate gigabytes.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Matthew Wilcox]

On Wed, Jul 06, 2022 at 11:05:25AM -0700, Alexei Starovoitov wrote:
> On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> > For example, I assume that a BPF program
> > has a fairly tight limit on how much memory it can cause to be allocated.
> > Right?
> 
> No. It's constrained by memcg limits only. It can allocate gigabytes.

I'm confused.  A BPF program is limited to executing 4096 insns and
using a maximum of 512 bytes of stack space, but it can allocate an
unlimited amount of heap?  That seems wrong.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Wed, Jul 06, 2022 at 07:21:29PM +0100, Matthew Wilcox wrote:
> On Wed, Jul 06, 2022 at 11:05:25AM -0700, Alexei Starovoitov wrote:
> > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> > > For example, I assume that a BPF program
> > > has a fairly tight limit on how much memory it can cause to be allocated.
> > > Right?
> > 
> > No. It's constrained by memcg limits only. It can allocate gigabytes.
> 
> I'm confused.  A BPF program is limited to executing 4096 insns and
> using a maximum of 512 bytes of stack space, but it can allocate an
> unlimited amount of heap?  That seems wrong.

4k insn limit was lifted years ago.
bpf progs are pretty close to be at parity with kernel modules.
Except that they are safe, portable, and users have full visibility into them.
It's not a blob of bytes unlike .ko.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Matthew Wilcox]

On Wed, Jul 06, 2022 at 11:26:35AM -0700, Alexei Starovoitov wrote:
> On Wed, Jul 06, 2022 at 07:21:29PM +0100, Matthew Wilcox wrote:
> > On Wed, Jul 06, 2022 at 11:05:25AM -0700, Alexei Starovoitov wrote:
> > > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> > > > For example, I assume that a BPF program
> > > > has a fairly tight limit on how much memory it can cause to be allocated.
> > > > Right?
> > > 
> > > No. It's constrained by memcg limits only. It can allocate gigabytes.
> > 
> > I'm confused.  A BPF program is limited to executing 4096 insns and
> > using a maximum of 512 bytes of stack space, but it can allocate an
> > unlimited amount of heap?  That seems wrong.
> 
> 4k insn limit was lifted years ago.

You might want to update the documentation.
https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html
still says 4096.

> bpf progs are pretty close to be at parity with kernel modules.
> Except that they are safe, portable, and users have full visibility into them.
> It's not a blob of bytes unlike .ko.

It doesn't seem unreasonable to expect them to behave like kernel
modules, then.  If they want to allocate memory in NMI context, then
they should get to preallocate it before they go into NMI context.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Wed, Jul 06, 2022 at 07:31:34PM +0100, Matthew Wilcox wrote:
> On Wed, Jul 06, 2022 at 11:26:35AM -0700, Alexei Starovoitov wrote:
> > On Wed, Jul 06, 2022 at 07:21:29PM +0100, Matthew Wilcox wrote:
> > > On Wed, Jul 06, 2022 at 11:05:25AM -0700, Alexei Starovoitov wrote:
> > > > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> > > > > For example, I assume that a BPF program
> > > > > has a fairly tight limit on how much memory it can cause to be allocated.
> > > > > Right?
> > > > 
> > > > No. It's constrained by memcg limits only. It can allocate gigabytes.
> > > 
> > > I'm confused.  A BPF program is limited to executing 4096 insns and
> > > using a maximum of 512 bytes of stack space, but it can allocate an
> > > unlimited amount of heap?  That seems wrong.
> > 
> > 4k insn limit was lifted years ago.
> 
> You might want to update the documentation.
> https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html
> still says 4096.

No. Please read what you're quoting first.

> > bpf progs are pretty close to be at parity with kernel modules.
> > Except that they are safe, portable, and users have full visibility into them.
> > It's not a blob of bytes unlike .ko.
> 
> It doesn't seem unreasonable to expect them to behave like kernel
> modules, then.  If they want to allocate memory in NMI context, then
> they should get to preallocate it before they go into NMI context.

You're still missing 'any context' part from the previous email.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Matthew Wilcox]

On Wed, Jul 06, 2022 at 11:36:19AM -0700, Alexei Starovoitov wrote:
> On Wed, Jul 06, 2022 at 07:31:34PM +0100, Matthew Wilcox wrote:
> > On Wed, Jul 06, 2022 at 11:26:35AM -0700, Alexei Starovoitov wrote:
> > > On Wed, Jul 06, 2022 at 07:21:29PM +0100, Matthew Wilcox wrote:
> > > > On Wed, Jul 06, 2022 at 11:05:25AM -0700, Alexei Starovoitov wrote:
> > > > > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> > > > > > For example, I assume that a BPF program
> > > > > > has a fairly tight limit on how much memory it can cause to be allocated.
> > > > > > Right?
> > > > > 
> > > > > No. It's constrained by memcg limits only. It can allocate gigabytes.
> > > > 
> > > > I'm confused.  A BPF program is limited to executing 4096 insns and
> > > > using a maximum of 512 bytes of stack space, but it can allocate an
> > > > unlimited amount of heap?  That seems wrong.
> > > 
> > > 4k insn limit was lifted years ago.
> > 
> > You might want to update the documentation.
> > https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html
> > still says 4096.
> 
> No. Please read what you're quoting first.

I did read it.  It says

: The only limit known to the user space is BPF_MAXINSNS (4096). It’s the
: maximum number of instructions that the unprivileged bpf program can have.

It really seems pretty clear to me.  You're saying my understanding
is wrong.  So it must be badly written.  Even now, I don't understand
how I've misunderstood it.

> > > bpf progs are pretty close to be at parity with kernel modules.
> > > Except that they are safe, portable, and users have full visibility into them.
> > > It's not a blob of bytes unlike .ko.
> > 
> > It doesn't seem unreasonable to expect them to behave like kernel
> > modules, then.  If they want to allocate memory in NMI context, then
> > they should get to preallocate it before they go into NMI context.
> 
> You're still missing 'any context' part from the previous email.

Really, this is not a productive way to respond.  I want to help
and you're just snarling at me.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Wed, Jul 06, 2022 at 07:40:44PM +0100, Matthew Wilcox wrote:
> On Wed, Jul 06, 2022 at 11:36:19AM -0700, Alexei Starovoitov wrote:
> > On Wed, Jul 06, 2022 at 07:31:34PM +0100, Matthew Wilcox wrote:
> > > On Wed, Jul 06, 2022 at 11:26:35AM -0700, Alexei Starovoitov wrote:
> > > > On Wed, Jul 06, 2022 at 07:21:29PM +0100, Matthew Wilcox wrote:
> > > > > On Wed, Jul 06, 2022 at 11:05:25AM -0700, Alexei Starovoitov wrote:
> > > > > > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> > > > > > > For example, I assume that a BPF program
> > > > > > > has a fairly tight limit on how much memory it can cause to be allocated.
> > > > > > > Right?
> > > > > > 
> > > > > > No. It's constrained by memcg limits only. It can allocate gigabytes.
> > > > > 
> > > > > I'm confused.  A BPF program is limited to executing 4096 insns and
> > > > > using a maximum of 512 bytes of stack space, but it can allocate an
> > > > > unlimited amount of heap?  That seems wrong.
> > > > 
> > > > 4k insn limit was lifted years ago.
> > > 
> > > You might want to update the documentation.
> > > https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html
> > > still says 4096.
> > 
> > No. Please read what you're quoting first.
> 
> I did read it.  It says
> 
> : The only limit known to the user space is BPF_MAXINSNS (4096). It’s the
> : maximum number of instructions that the unprivileged bpf program can have.
> 
> It really seems pretty clear to me.  You're saying my understanding
> is wrong.  So it must be badly written.  Even now, I don't understand
> how I've misunderstood it.

huh? Still missing 'unprivileged' in the above ?
and completely ignoring the rest of the paragraph in the link above?

> > > > bpf progs are pretty close to be at parity with kernel modules.
> > > > Except that they are safe, portable, and users have full visibility into them.
> > > > It's not a blob of bytes unlike .ko.
> > > 
> > > It doesn't seem unreasonable to expect them to behave like kernel
> > > modules, then.  If they want to allocate memory in NMI context, then
> > > they should get to preallocate it before they go into NMI context.
> > 
> > You're still missing 'any context' part from the previous email.
> 
> Really, this is not a productive way to respond.  I want to help
> and you're just snarling at me.

To help you need to understand what bpf is while you're failing
to read the doc.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Matthew Wilcox]

On Wed, Jul 06, 2022 at 11:51:03AM -0700, Alexei Starovoitov wrote:
> On Wed, Jul 06, 2022 at 07:40:44PM +0100, Matthew Wilcox wrote:
> > On Wed, Jul 06, 2022 at 11:36:19AM -0700, Alexei Starovoitov wrote:
> > > On Wed, Jul 06, 2022 at 07:31:34PM +0100, Matthew Wilcox wrote:
> > > > On Wed, Jul 06, 2022 at 11:26:35AM -0700, Alexei Starovoitov wrote:
> > > > > On Wed, Jul 06, 2022 at 07:21:29PM +0100, Matthew Wilcox wrote:
> > > > > > On Wed, Jul 06, 2022 at 11:05:25AM -0700, Alexei Starovoitov wrote:
> > > > > > > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> > > > > > > > For example, I assume that a BPF program
> > > > > > > > has a fairly tight limit on how much memory it can cause to be allocated.
> > > > > > > > Right?
> > > > > > > 
> > > > > > > No. It's constrained by memcg limits only. It can allocate gigabytes.
> > > > > > 
> > > > > > I'm confused.  A BPF program is limited to executing 4096 insns and
> > > > > > using a maximum of 512 bytes of stack space, but it can allocate an
> > > > > > unlimited amount of heap?  That seems wrong.
> > > > > 
> > > > > 4k insn limit was lifted years ago.
> > > > 
> > > > You might want to update the documentation.
> > > > https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html
> > > > still says 4096.
> > > 
> > > No. Please read what you're quoting first.
> > 
> > I did read it.  It says
> > 
> > : The only limit known to the user space is BPF_MAXINSNS (4096). It’s the
> > : maximum number of instructions that the unprivileged bpf program can have.
> > 
> > It really seems pretty clear to me.  You're saying my understanding
> > is wrong.  So it must be badly written.  Even now, I don't understand
> > how I've misunderstood it.
> 
> huh? Still missing 'unprivileged' in the above ?
> and completely ignoring the rest of the paragraph in the link above?

Are you saying that unprivileged programs are not allowed to allocate
memory?  Or that there is a limit on the amount of heap memory that
unprivileged programs are allowed to allocate.

> > > > > bpf progs are pretty close to be at parity with kernel modules.
> > > > > Except that they are safe, portable, and users have full visibility into them.
> > > > > It's not a blob of bytes unlike .ko.
> > > > 
> > > > It doesn't seem unreasonable to expect them to behave like kernel
> > > > modules, then.  If they want to allocate memory in NMI context, then
> > > > they should get to preallocate it before they go into NMI context.
> > > 
> > > You're still missing 'any context' part from the previous email.
> > 
> > Really, this is not a productive way to respond.  I want to help
> > and you're just snarling at me.
> 
> To help you need to understand what bpf is while you're failing
> to read the doc.

Part of working with other people is understanding that they don't know
as much as you do about your thing, and at the same time understanding
that you don't know as much as they do about their thing.  That means
explaining things in a way which makes sense to them instead of getting
all huffy when they don't understand the details of your thing.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Michal Hocko]

On Wed 06-07-22 11:05:25, Alexei Starovoitov wrote:
> On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
[...]
> > For example, I assume that a BPF program
> > has a fairly tight limit on how much memory it can cause to be allocated.
> > Right?
> 
> No. It's constrained by memcg limits only. It can allocate gigabytes.
 
I have very briefly had a look at the core allocator parts (please note
that my understanding of BPF is really close to zero so I might be
missing a lot of implicit stuff). So by constrained by memcg you mean
__GFP_ACCOUNT done from the allocation context (irq_work). The complete
gfp mask is GFP_ATOMIC | __GFP_NOMEMALLOC | __GFP_NOWARN | __GFP_ACCOUNT
which means this allocation is not allowed to sleep and GFP_ATOMIC
implies __GFP_HIGH to say that access to memory reserves is allowed.
Memcg charging code interprets this that the hard limit can be breached
under assumption that these are rare and will be compensated in some
way. The bulk allocator implemented here, however, doesn't reflect that
and continues allocating as it sees a success so the breach of the limit
is only bound by the number of objects to be allocated. If those can be
really large then this is a clear problem and __GFP_HIGH usage is not
really appropriate.

Also, I do not see any tracking of the overall memory sitting in these
pools and I think this would be really appropriate. As there doesn't
seem to be any reclaim mechanism implemented this can hide quite some
unreachable memory.

Finally it is not really clear to what kind of entity is the life time
of these caches bound to. Let's say the system goes OOM, is any process
responsible for it and a clean up would be done if it gets killed?

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Fri, Jul 08, 2022 at 03:41:47PM +0200, Michal Hocko wrote:
> On Wed 06-07-22 11:05:25, Alexei Starovoitov wrote:
> > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> [...]
> > > For example, I assume that a BPF program
> > > has a fairly tight limit on how much memory it can cause to be allocated.
> > > Right?
> > 
> > No. It's constrained by memcg limits only. It can allocate gigabytes.
>  
> I have very briefly had a look at the core allocator parts (please note
> that my understanding of BPF is really close to zero so I might be
> missing a lot of implicit stuff). So by constrained by memcg you mean
> __GFP_ACCOUNT done from the allocation context (irq_work). The complete
> gfp mask is GFP_ATOMIC | __GFP_NOMEMALLOC | __GFP_NOWARN | __GFP_ACCOUNT
> which means this allocation is not allowed to sleep and GFP_ATOMIC
> implies __GFP_HIGH to say that access to memory reserves is allowed.
> Memcg charging code interprets this that the hard limit can be breached
> under assumption that these are rare and will be compensated in some
> way. The bulk allocator implemented here, however, doesn't reflect that
> and continues allocating as it sees a success so the breach of the limit
> is only bound by the number of objects to be allocated. If those can be
> really large then this is a clear problem and __GFP_HIGH usage is not
> really appropriate.

That was a copy paste from the networking stack. See kmalloc_reserve().
Not sure whether it's a bug there or not.
In a separate thread we've agreed to convert all of bpf allocations
to GFP_NOWAIT. For this patch set I've already fixed it in my branch.

> Also, I do not see any tracking of the overall memory sitting in these
> pools and I think this would be really appropriate. As there doesn't
> seem to be any reclaim mechanism implemented this can hide quite some
> unreachable memory.
> 
> Finally it is not really clear to what kind of entity is the life time
> of these caches bound to. Let's say the system goes OOM, is any process
> responsible for it and a clean up would be done if it gets killed?

We've been asking these questions for years and have been trying to
come up with a solution.
bpf progs are not analogous to user space processes. 
There are bpf progs that function completely without user space component.
bpf progs are pretty close to be full featured kernel modules with
the difference that bpf progs are safe, portable and users have
full visibility into them (source code, line info, type info, etc)
They are not binary blobs unlike kernel modules.
But from OOM perspective they're pretty much like .ko-s.
Which kernel module would you force unload when system is OOMing ?
Force unloading ko-s will likely crash the system.
Force unloading bpf progs maybe equally bad. The system won't crash,
but it may be a sorrow state. The bpf could have been doing security
enforcement or network firewall or providing key insights to critical
user space components like systemd or health check daemon.
We've been discussing ideas on how to rank and auto cleanup
the system state when progs have to be unloaded. Some sort of
destructor mechanism. Fingers crossed we will have it eventually.
bpf infra keeps track of everything, of course.
Technically we can detach, unpin and unload everything and all memory
will be returned back to the system.
Anyhow not a new problem. Orthogonal to this patch set.
bpf progs have been doing memory allocation from day one. 8 years ago.
This patch set is trying to make it 100% safe.
Currently it's 99% safe.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Yosry Ahmed]

On Fri, Jul 8, 2022 at 10:49 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Fri, Jul 08, 2022 at 03:41:47PM +0200, Michal Hocko wrote:
> > On Wed 06-07-22 11:05:25, Alexei Starovoitov wrote:
> > > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> > [...]
> > > > For example, I assume that a BPF program
> > > > has a fairly tight limit on how much memory it can cause to be allocated.
> > > > Right?
> > >
> > > No. It's constrained by memcg limits only. It can allocate gigabytes.
> >
> > I have very briefly had a look at the core allocator parts (please note
> > that my understanding of BPF is really close to zero so I might be
> > missing a lot of implicit stuff). So by constrained by memcg you mean
> > __GFP_ACCOUNT done from the allocation context (irq_work). The complete
> > gfp mask is GFP_ATOMIC | __GFP_NOMEMALLOC | __GFP_NOWARN | __GFP_ACCOUNT
> > which means this allocation is not allowed to sleep and GFP_ATOMIC
> > implies __GFP_HIGH to say that access to memory reserves is allowed.
> > Memcg charging code interprets this that the hard limit can be breached
> > under assumption that these are rare and will be compensated in some
> > way. The bulk allocator implemented here, however, doesn't reflect that
> > and continues allocating as it sees a success so the breach of the limit
> > is only bound by the number of objects to be allocated. If those can be
> > really large then this is a clear problem and __GFP_HIGH usage is not
> > really appropriate.
>
> That was a copy paste from the networking stack. See kmalloc_reserve().
> Not sure whether it's a bug there or not.
> In a separate thread we've agreed to convert all of bpf allocations
> to GFP_NOWAIT. For this patch set I've already fixed it in my branch.
>
> > Also, I do not see any tracking of the overall memory sitting in these
> > pools and I think this would be really appropriate. As there doesn't
> > seem to be any reclaim mechanism implemented this can hide quite some
> > unreachable memory.
> >
> > Finally it is not really clear to what kind of entity is the life time
> > of these caches bound to. Let's say the system goes OOM, is any process
> > responsible for it and a clean up would be done if it gets killed?
>
> We've been asking these questions for years and have been trying to
> come up with a solution.
> bpf progs are not analogous to user space processes.
> There are bpf progs that function completely without user space component.
> bpf progs are pretty close to be full featured kernel modules with
> the difference that bpf progs are safe, portable and users have
> full visibility into them (source code, line info, type info, etc)
> They are not binary blobs unlike kernel modules.
> But from OOM perspective they're pretty much like .ko-s.
> Which kernel module would you force unload when system is OOMing ?
> Force unloading ko-s will likely crash the system.
> Force unloading bpf progs maybe equally bad. The system won't crash,
> but it may be a sorrow state. The bpf could have been doing security
> enforcement or network firewall or providing key insights to critical
> user space components like systemd or health check daemon.
> We've been discussing ideas on how to rank and auto cleanup
> the system state when progs have to be unloaded. Some sort of
> destructor mechanism. Fingers crossed we will have it eventually.
> bpf infra keeps track of everything, of course.
> Technically we can detach, unpin and unload everything and all memory
> will be returned back to the system.
> Anyhow not a new problem. Orthogonal to this patch set.
> bpf progs have been doing memory allocation from day one. 8 years ago.
> This patch set is trying to make it 100% safe.
> Currently it's 99% safe.
>

I think part of Michal's concern here is about memory sitting in
caches that is not yet used by any bpf allocation. I honestly didn't
look at the patches, so I don't know, but if the amount of cached
memory in the bpf allocator is significant then maybe it's worth
reclaiming it on memory pressure? Just thinking out loud.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Shakeel Butt]

On Fri, Jul 08, 2022 at 10:48:58AM -0700, Alexei Starovoitov wrote:
> On Fri, Jul 08, 2022 at 03:41:47PM +0200, Michal Hocko wrote:
> > On Wed 06-07-22 11:05:25, Alexei Starovoitov wrote:
> > > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> > [...]
> > > > For example, I assume that a BPF program
> > > > has a fairly tight limit on how much memory it can cause to be allocated.
> > > > Right?
> > > 
> > > No. It's constrained by memcg limits only. It can allocate gigabytes.
> >  
> > I have very briefly had a look at the core allocator parts (please note
> > that my understanding of BPF is really close to zero so I might be
> > missing a lot of implicit stuff). So by constrained by memcg you mean
> > __GFP_ACCOUNT done from the allocation context (irq_work). The complete
> > gfp mask is GFP_ATOMIC | __GFP_NOMEMALLOC | __GFP_NOWARN | __GFP_ACCOUNT
> > which means this allocation is not allowed to sleep and GFP_ATOMIC
> > implies __GFP_HIGH to say that access to memory reserves is allowed.
> > Memcg charging code interprets this that the hard limit can be breached
> > under assumption that these are rare and will be compensated in some
> > way. The bulk allocator implemented here, however, doesn't reflect that
> > and continues allocating as it sees a success so the breach of the limit
> > is only bound by the number of objects to be allocated. If those can be
> > really large then this is a clear problem and __GFP_HIGH usage is not
> > really appropriate.
> 
> That was a copy paste from the networking stack. See kmalloc_reserve().
> Not sure whether it's a bug there or not.

kmalloc_reserve() is good. Most of calls to kmalloc_reserve() are for
skbs and we don't use __GFP_ACCOUNT for skbs. Actually skbs are charged
to memcg through a separate interface (i.e. mem_cgroup_charge_skmem())

> In a separate thread we've agreed to convert all of bpf allocations
> to GFP_NOWAIT. For this patch set I've already fixed it in my branch.
> 
> > Also, I do not see any tracking of the overall memory sitting in these
> > pools and I think this would be really appropriate. As there doesn't
> > seem to be any reclaim mechanism implemented this can hide quite some
> > unreachable memory.
> > 
> > Finally it is not really clear to what kind of entity is the life time
> > of these caches bound to. Let's say the system goes OOM, is any process
> > responsible for it and a clean up would be done if it gets killed?
> 
> We've been asking these questions for years and have been trying to
> come up with a solution.
> bpf progs are not analogous to user space processes. 
> There are bpf progs that function completely without user space component.
> bpf progs are pretty close to be full featured kernel modules with
> the difference that bpf progs are safe, portable and users have
> full visibility into them (source code, line info, type info, etc)
> They are not binary blobs unlike kernel modules.
> But from OOM perspective they're pretty much like .ko-s.
> Which kernel module would you force unload when system is OOMing ?
> Force unloading ko-s will likely crash the system.
> Force unloading bpf progs maybe equally bad. The system won't crash,
> but it may be a sorrow state. The bpf could have been doing security
> enforcement or network firewall or providing key insights to critical
> user space components like systemd or health check daemon.
> We've been discussing ideas on how to rank and auto cleanup
> the system state when progs have to be unloaded. Some sort of
> destructor mechanism. Fingers crossed we will have it eventually.
> bpf infra keeps track of everything, of course.
> Technically we can detach, unpin and unload everything and all memory
> will be returned back to the system.
> Anyhow not a new problem. Orthogonal to this patch set.
> bpf progs have been doing memory allocation from day one. 8 years ago.
> This patch set is trying to make it 100% safe.
> Currently it's 99% safe.

Most probably Michal's comment was on free objects sitting in the caches
(also pointed out by Yosry). Should we drain them on memory pressure /
OOM or should we ignore them as the amount of memory is not significant?

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Fri, Jul 8, 2022 at 2:55 PM Shakeel Butt <shakeelb@google.com> wrote:
>
> On Fri, Jul 08, 2022 at 10:48:58AM -0700, Alexei Starovoitov wrote:
> > On Fri, Jul 08, 2022 at 03:41:47PM +0200, Michal Hocko wrote:
> > > On Wed 06-07-22 11:05:25, Alexei Starovoitov wrote:
> > > > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote:
> > > [...]
> > > > > For example, I assume that a BPF program
> > > > > has a fairly tight limit on how much memory it can cause to be allocated.
> > > > > Right?
> > > >
> > > > No. It's constrained by memcg limits only. It can allocate gigabytes.
> > >
> > > I have very briefly had a look at the core allocator parts (please note
> > > that my understanding of BPF is really close to zero so I might be
> > > missing a lot of implicit stuff). So by constrained by memcg you mean
> > > __GFP_ACCOUNT done from the allocation context (irq_work). The complete
> > > gfp mask is GFP_ATOMIC | __GFP_NOMEMALLOC | __GFP_NOWARN | __GFP_ACCOUNT
> > > which means this allocation is not allowed to sleep and GFP_ATOMIC
> > > implies __GFP_HIGH to say that access to memory reserves is allowed.
> > > Memcg charging code interprets this that the hard limit can be breached
> > > under assumption that these are rare and will be compensated in some
> > > way. The bulk allocator implemented here, however, doesn't reflect that
> > > and continues allocating as it sees a success so the breach of the limit
> > > is only bound by the number of objects to be allocated. If those can be
> > > really large then this is a clear problem and __GFP_HIGH usage is not
> > > really appropriate.
> >
> > That was a copy paste from the networking stack. See kmalloc_reserve().
> > Not sure whether it's a bug there or not.
>
> kmalloc_reserve() is good. Most of calls to kmalloc_reserve() are for
> skbs and we don't use __GFP_ACCOUNT for skbs. Actually skbs are charged
> to memcg through a separate interface (i.e. mem_cgroup_charge_skmem())
>
> > In a separate thread we've agreed to convert all of bpf allocations
> > to GFP_NOWAIT. For this patch set I've already fixed it in my branch.
> >
> > > Also, I do not see any tracking of the overall memory sitting in these
> > > pools and I think this would be really appropriate. As there doesn't
> > > seem to be any reclaim mechanism implemented this can hide quite some
> > > unreachable memory.
> > >
> > > Finally it is not really clear to what kind of entity is the life time
> > > of these caches bound to. Let's say the system goes OOM, is any process
> > > responsible for it and a clean up would be done if it gets killed?
> >
> > We've been asking these questions for years and have been trying to
> > come up with a solution.
> > bpf progs are not analogous to user space processes.
> > There are bpf progs that function completely without user space component.
> > bpf progs are pretty close to be full featured kernel modules with
> > the difference that bpf progs are safe, portable and users have
> > full visibility into them (source code, line info, type info, etc)
> > They are not binary blobs unlike kernel modules.
> > But from OOM perspective they're pretty much like .ko-s.
> > Which kernel module would you force unload when system is OOMing ?
> > Force unloading ko-s will likely crash the system.
> > Force unloading bpf progs maybe equally bad. The system won't crash,
> > but it may be a sorrow state. The bpf could have been doing security
> > enforcement or network firewall or providing key insights to critical
> > user space components like systemd or health check daemon.
> > We've been discussing ideas on how to rank and auto cleanup
> > the system state when progs have to be unloaded. Some sort of
> > destructor mechanism. Fingers crossed we will have it eventually.
> > bpf infra keeps track of everything, of course.
> > Technically we can detach, unpin and unload everything and all memory
> > will be returned back to the system.
> > Anyhow not a new problem. Orthogonal to this patch set.
> > bpf progs have been doing memory allocation from day one. 8 years ago.
> > This patch set is trying to make it 100% safe.
> > Currently it's 99% safe.
>
> Most probably Michal's comment was on free objects sitting in the caches
> (also pointed out by Yosry). Should we drain them on memory pressure /
> OOM or should we ignore them as the amount of memory is not significant?

Are you suggesting to design a shrinker for 0.01% of the memory
consumed by bpf?
And such drain would help... how?

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Shakeel Butt]

On Sat, Jul 09, 2022 at 10:26:23PM -0700, Alexei Starovoitov wrote:
> On Fri, Jul 8, 2022 at 2:55 PM Shakeel Butt <shakeelb@google.com> wrote:
[...]
> >
> > Most probably Michal's comment was on free objects sitting in the caches
> > (also pointed out by Yosry). Should we drain them on memory pressure /
> > OOM or should we ignore them as the amount of memory is not significant?
> 
> Are you suggesting to design a shrinker for 0.01% of the memory
> consumed by bpf?

No, just claim that the memory sitting on such caches is insignificant.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Michal Hocko]

On Sun 10-07-22 07:32:13, Shakeel Butt wrote:
> On Sat, Jul 09, 2022 at 10:26:23PM -0700, Alexei Starovoitov wrote:
> > On Fri, Jul 8, 2022 at 2:55 PM Shakeel Butt <shakeelb@google.com> wrote:
> [...]
> > >
> > > Most probably Michal's comment was on free objects sitting in the caches
> > > (also pointed out by Yosry). Should we drain them on memory pressure /
> > > OOM or should we ignore them as the amount of memory is not significant?
> > 
> > Are you suggesting to design a shrinker for 0.01% of the memory
> > consumed by bpf?
> 
> No, just claim that the memory sitting on such caches is insignificant.

yes, that is not really clear from the patch description. Earlier you
have said that the memory consumed might go into GBs. If that is a
memory that is actively used and not really reclaimable then bad luck.
There are other users like that in the kernel and this is not a new
problem. I think it would really help to add a counter to describe both
the overall memory claimed by the bpf allocator and actively used
portion of it. If you use our standard vmstat infrastructure then we can
easily show that information in the OOM report.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Mon, Jul 11, 2022 at 02:15:07PM +0200, Michal Hocko wrote:
> On Sun 10-07-22 07:32:13, Shakeel Butt wrote:
> > On Sat, Jul 09, 2022 at 10:26:23PM -0700, Alexei Starovoitov wrote:
> > > On Fri, Jul 8, 2022 at 2:55 PM Shakeel Butt <shakeelb@google.com> wrote:
> > [...]
> > > >
> > > > Most probably Michal's comment was on free objects sitting in the caches
> > > > (also pointed out by Yosry). Should we drain them on memory pressure /
> > > > OOM or should we ignore them as the amount of memory is not significant?
> > > 
> > > Are you suggesting to design a shrinker for 0.01% of the memory
> > > consumed by bpf?
> > 
> > No, just claim that the memory sitting on such caches is insignificant.
> 
> yes, that is not really clear from the patch description. Earlier you
> have said that the memory consumed might go into GBs. If that is a
> memory that is actively used and not really reclaimable then bad luck.
> There are other users like that in the kernel and this is not a new
> problem. I think it would really help to add a counter to describe both
> the overall memory claimed by the bpf allocator and actively used
> portion of it. If you use our standard vmstat infrastructure then we can
> easily show that information in the OOM report.

OOM report can potentially be extended with info about bpf consumed
memory, but it's not clear whether it will help OOM analysis.
bpftool map show
prints all map data already.
Some devs use bpf to inspect bpf maps for finer details in run-time.
drgn scripts pull that data from crash dumps.
There is no need for new counters.
The idea of bpf specific counters/limits was rejected by memcg folks.

> OK, thanks for the clarification. There is still one thing that is not
> really clear to me. Without a proper ownership bound to any process why
> is it desired/helpful to account the memory to a memcg?

The first step is to have a limit. memcg provides it.

> We have discussed something similar in a different email thread and I
> still didn't manage to find time to put all the parts together. But if
> the initiator (or however you call the process which loads the program)
> exits then this might be the last process in the specific cgroup and so
> it can be offlined and mostly invisible to an admin.

Roman already sent reparenting fix:
https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/

> As you have explained there is nothing really actionable on this memory
> by the OOM killer either. So does it actually buy us much to account?

It will be actionable. One step at a time.
In the other thread we've discussed an idea to make memcg selectable when
bpf objects are created. The user might create a special memcg and use it for
all things bpf. This might be the way to provide bpf specific accounting
and limits.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Michal Hocko]

On Mon 11-07-22 21:39:14, Alexei Starovoitov wrote:
> On Mon, Jul 11, 2022 at 02:15:07PM +0200, Michal Hocko wrote:
> > On Sun 10-07-22 07:32:13, Shakeel Butt wrote:
> > > On Sat, Jul 09, 2022 at 10:26:23PM -0700, Alexei Starovoitov wrote:
> > > > On Fri, Jul 8, 2022 at 2:55 PM Shakeel Butt <shakeelb@google.com> wrote:
> > > [...]
> > > > >
> > > > > Most probably Michal's comment was on free objects sitting in the caches
> > > > > (also pointed out by Yosry). Should we drain them on memory pressure /
> > > > > OOM or should we ignore them as the amount of memory is not significant?
> > > > 
> > > > Are you suggesting to design a shrinker for 0.01% of the memory
> > > > consumed by bpf?
> > > 
> > > No, just claim that the memory sitting on such caches is insignificant.
> > 
> > yes, that is not really clear from the patch description. Earlier you
> > have said that the memory consumed might go into GBs. If that is a
> > memory that is actively used and not really reclaimable then bad luck.
> > There are other users like that in the kernel and this is not a new
> > problem. I think it would really help to add a counter to describe both
> > the overall memory claimed by the bpf allocator and actively used
> > portion of it. If you use our standard vmstat infrastructure then we can
> > easily show that information in the OOM report.
> 
> OOM report can potentially be extended with info about bpf consumed
> memory, but it's not clear whether it will help OOM analysis.

If GBs of memory can be sitting there then it is surely an interesting
information to have when seeing OOM. One of the big shortcomings of the
OOM analysis is unaccounted memory.

> bpftool map show
> prints all map data already.
> Some devs use bpf to inspect bpf maps for finer details in run-time.
> drgn scripts pull that data from crash dumps.
> There is no need for new counters.
> The idea of bpf specific counters/limits was rejected by memcg folks.

I would argue that integration into vmstat is useful not only for oom
analysis but also for regular health check scripts watching /proc/vmstat
content. I do not think most of those generic tools are BPF aware. So
unless there is a good reason to not account this memory there then I
would vote for adding them. They are cheap and easy to integrate.
 
> > OK, thanks for the clarification. There is still one thing that is not
> > really clear to me. Without a proper ownership bound to any process why
> > is it desired/helpful to account the memory to a memcg?
> 
> The first step is to have a limit. memcg provides it.

I am sorry but this doesn't really explain it. Could you elaborate
please? Is the limit supposed to protect against adversaries? Or is it
just to prevent from accidental runaways? Is it purely for accounting
purposes?

> > We have discussed something similar in a different email thread and I
> > still didn't manage to find time to put all the parts together. But if
> > the initiator (or however you call the process which loads the program)
> > exits then this might be the last process in the specific cgroup and so
> > it can be offlined and mostly invisible to an admin.
> 
> Roman already sent reparenting fix:
> https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/

Reparenting is nice but not a silver bullet. Consider a shallow
hierarchy where the charging happens in the first level under the root
memcg. Reparenting to the root is just pushing everything under the
system resources category.
 
> > As you have explained there is nothing really actionable on this memory
> > by the OOM killer either. So does it actually buy us much to account?
> 
> It will be actionable. One step at a time.
> In the other thread we've discussed an idea to make memcg selectable when
> bpf objects are created. The user might create a special memcg and use it for
> all things bpf. This might be the way to provide bpf specific accounting
> and limits.

Do you have a reference for those discussions?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Yafang Shao]

On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Mon 11-07-22 21:39:14, Alexei Starovoitov wrote:
> > On Mon, Jul 11, 2022 at 02:15:07PM +0200, Michal Hocko wrote:
> > > On Sun 10-07-22 07:32:13, Shakeel Butt wrote:
> > > > On Sat, Jul 09, 2022 at 10:26:23PM -0700, Alexei Starovoitov wrote:
> > > > > On Fri, Jul 8, 2022 at 2:55 PM Shakeel Butt <shakeelb@google.com> wrote:
> > > > [...]
> > > > > >
> > > > > > Most probably Michal's comment was on free objects sitting in the caches
> > > > > > (also pointed out by Yosry). Should we drain them on memory pressure /
> > > > > > OOM or should we ignore them as the amount of memory is not significant?
> > > > >
> > > > > Are you suggesting to design a shrinker for 0.01% of the memory
> > > > > consumed by bpf?
> > > >
> > > > No, just claim that the memory sitting on such caches is insignificant.
> > >
> > > yes, that is not really clear from the patch description. Earlier you
> > > have said that the memory consumed might go into GBs. If that is a
> > > memory that is actively used and not really reclaimable then bad luck.
> > > There are other users like that in the kernel and this is not a new
> > > problem. I think it would really help to add a counter to describe both
> > > the overall memory claimed by the bpf allocator and actively used
> > > portion of it. If you use our standard vmstat infrastructure then we can
> > > easily show that information in the OOM report.
> >
> > OOM report can potentially be extended with info about bpf consumed
> > memory, but it's not clear whether it will help OOM analysis.
>
> If GBs of memory can be sitting there then it is surely an interesting
> information to have when seeing OOM. One of the big shortcomings of the
> OOM analysis is unaccounted memory.
>
> > bpftool map show
> > prints all map data already.
> > Some devs use bpf to inspect bpf maps for finer details in run-time.
> > drgn scripts pull that data from crash dumps.
> > There is no need for new counters.
> > The idea of bpf specific counters/limits was rejected by memcg folks.
>
> I would argue that integration into vmstat is useful not only for oom
> analysis but also for regular health check scripts watching /proc/vmstat
> content. I do not think most of those generic tools are BPF aware. So
> unless there is a good reason to not account this memory there then I
> would vote for adding them. They are cheap and easy to integrate.
>
> > > OK, thanks for the clarification. There is still one thing that is not
> > > really clear to me. Without a proper ownership bound to any process why
> > > is it desired/helpful to account the memory to a memcg?
> >
> > The first step is to have a limit. memcg provides it.
>
> I am sorry but this doesn't really explain it. Could you elaborate
> please? Is the limit supposed to protect against adversaries? Or is it
> just to prevent from accidental runaways? Is it purely for accounting
> purposes?
>
> > > We have discussed something similar in a different email thread and I
> > > still didn't manage to find time to put all the parts together. But if
> > > the initiator (or however you call the process which loads the program)
> > > exits then this might be the last process in the specific cgroup and so
> > > it can be offlined and mostly invisible to an admin.
> >
> > Roman already sent reparenting fix:
> > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
>
> Reparenting is nice but not a silver bullet. Consider a shallow
> hierarchy where the charging happens in the first level under the root
> memcg. Reparenting to the root is just pushing everything under the
> system resources category.
>

Agreed. That's why I don't like reparenting.
Reparenting just reparent the charged pages and then redirect the new
charge, but can't reparents the 'limit' of the original memcg.
So it is a risk if the original memcg is still being charged. We have
to forbid the destruction of the original memcg.

> > > As you have explained there is nothing really actionable on this memory
> > > by the OOM killer either. So does it actually buy us much to account?
> >
> > It will be actionable. One step at a time.
> > In the other thread we've discussed an idea to make memcg selectable when
> > bpf objects are created. The user might create a special memcg and use it for
> > all things bpf. This might be the way to provide bpf specific accounting
> > and limits.
>
> Do you have a reference for those discussions?
>

I think it is https://lore.kernel.org/bpf/CALOAHbCM=ZxwutQOPmJx2LKY3Pd_hs+8v8r4-ybwPbBNBuNjXA@mail.gmail.com/
.
Introducing independent memcg to manage pinned bpf programs and maps
and forbid the user to destroy them if bpf programs are not unpinned,
that's the best workaround so sar, per my analysis.

-- 
Regards
Yafang

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Michal Hocko]

On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
[...]
> > > Roman already sent reparenting fix:
> > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
> >
> > Reparenting is nice but not a silver bullet. Consider a shallow
> > hierarchy where the charging happens in the first level under the root
> > memcg. Reparenting to the root is just pushing everything under the
> > system resources category.
> >
> 
> Agreed. That's why I don't like reparenting.
> Reparenting just reparent the charged pages and then redirect the new
> charge, but can't reparents the 'limit' of the original memcg.
> So it is a risk if the original memcg is still being charged. We have
> to forbid the destruction of the original memcg.

yes, I was toying with an idea like that. I guess we really want a
measure to keep cgroups around if they are bound to a resource which is
sticky itself. I am not sure how many other resources like BPF (aka
module like) we already do charge for memcg but considering the
potential memory consumption just reparenting will not help in general
case I am afraid.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Shakeel Butt]

CCing Yosry, Muchun & Johannes

On Tue, Jul 12, 2022 at 2:52 AM Michal Hocko <mhocko@suse.com> wrote:
>
> On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> > On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
> [...]
> > > > Roman already sent reparenting fix:
> > > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
> > >
> > > Reparenting is nice but not a silver bullet. Consider a shallow
> > > hierarchy where the charging happens in the first level under the root
> > > memcg. Reparenting to the root is just pushing everything under the
> > > system resources category.
> > >
> >
> > Agreed. That's why I don't like reparenting.
> > Reparenting just reparent the charged pages and then redirect the new
> > charge, but can't reparents the 'limit' of the original memcg.
> > So it is a risk if the original memcg is still being charged. We have
> > to forbid the destruction of the original memcg.
>
> yes, I was toying with an idea like that. I guess we really want a
> measure to keep cgroups around if they are bound to a resource which is
> sticky itself. I am not sure how many other resources like BPF (aka
> module like) we already do charge for memcg but considering the
> potential memory consumption just reparenting will not help in general
> case I am afraid.

Another very obvious example is the filesystem shared between multiple
jobs. We had a similar discussion [1] on LRU reparenting patch series.

For this use-case internally we have a memcg= mount option where the
given memcg is the common ancestor (think of pod in k8s environment)
of the jobs who are sharing the filesystem.

[1] https://lore.kernel.org/all/20210330101531.82752-1-songmuchun@bytedance.com/

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Tejun Heo]

Hello,

On Tue, Jul 12, 2022 at 08:25:24AM -0700, Shakeel Butt wrote:
> Another very obvious example is the filesystem shared between multiple
> jobs. We had a similar discussion [1] on LRU reparenting patch series.

Hmm... if I'm understanding correctly, what's discussed in [1] can be solved
with proper reparenting and nesting, right?

> For this use-case internally we have a memcg= mount option where the
> given memcg is the common ancestor (think of pod in k8s environment)
> of the jobs who are sharing the filesystem.

Can you elaborate a bit more on this? We've never really supported correctly
accounting pages shared across cgroups because it can be very complicating
and the use cases aren't that wide-spread. What's being shared? How big is
the shared portion in relation to total memory usage? What's the cgroup
topology like?

Thanks.

-- 
tejun

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Shakeel Butt]

On Tue, Jul 12, 2022 at 9:32 AM Tejun Heo <tj@kernel.org> wrote:
>
> Hello,
>
> On Tue, Jul 12, 2022 at 08:25:24AM -0700, Shakeel Butt wrote:
> > Another very obvious example is the filesystem shared between multiple
> > jobs. We had a similar discussion [1] on LRU reparenting patch series.
>
> Hmm... if I'm understanding correctly, what's discussed in [1] can be solved
> with proper reparenting and nesting, right?
>

To some extent i.e. the zombies will go away but the accounting/stats
of the sub-jobs will be nondeterministic until all the possible shared
stuff is reparented. Let me give a more concrete example below.

> > For this use-case internally we have a memcg= mount option where the
> > given memcg is the common ancestor (think of pod in k8s environment)
> > of the jobs who are sharing the filesystem.
>
> Can you elaborate a bit more on this? We've never really supported correctly
> accounting pages shared across cgroups because it can be very complicating
> and the use cases aren't that wide-spread. What's being shared? How big is
> the shared portion in relation to total memory usage? What's the cgroup
> topology like?
>

One use-case we have is a build & test service which runs independent
builds and tests but all the build utilities (compiler, linker,
libraries) are shared between those builds and tests.

In terms of topology, the service has a top level cgroup (P) and all
independent builds and tests run in their own cgroup under P. These
builds/tests continuously come and go.

This service continuously monitors all the builds/tests running and
may kill some based on some criteria which includes memory usage.
However the memory usage is nondeterministic and killing a specific
build/test may not really free memory if most of the memory charged to
it is from shared build utilities.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Tejun Heo]

Hello,

On Tue, Jul 12, 2022 at 10:26:22AM -0700, Shakeel Butt wrote:
> One use-case we have is a build & test service which runs independent
> builds and tests but all the build utilities (compiler, linker,
> libraries) are shared between those builds and tests.
> 
> In terms of topology, the service has a top level cgroup (P) and all
> independent builds and tests run in their own cgroup under P. These
> builds/tests continuously come and go.
> 
> This service continuously monitors all the builds/tests running and
> may kill some based on some criteria which includes memory usage.
> However the memory usage is nondeterministic and killing a specific
> build/test may not really free memory if most of the memory charged to
> it is from shared build utilities.

That doesn't sound too unusual. So, one saving grace here is that the memory
pressure in the stressed cgroup should trigger reclaim of the shared memory
which will be likely picked up by someone else, hopefully, under less memory
pressure. Can you give more concerete details? ie. describe a failing
scenario with actual ballpark memory numbers?

FWIW, at least from generic resource constrol standpoint, I think it may
make sense to have a way to escape certain resources to an ancestor for
shared resources provided that we can come up with a sane interface.

Thanks.

-- 
tejun

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Shakeel Butt]

Ccing Mina who actually worked on upstreaming this. See [1] for
previous discussion and more use-cases.

[1] https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/

On Tue, Jul 12, 2022 at 10:36 AM Tejun Heo <tj@kernel.org> wrote:
>
> Hello,
>
> On Tue, Jul 12, 2022 at 10:26:22AM -0700, Shakeel Butt wrote:
> > One use-case we have is a build & test service which runs independent
> > builds and tests but all the build utilities (compiler, linker,
> > libraries) are shared between those builds and tests.
> >
> > In terms of topology, the service has a top level cgroup (P) and all
> > independent builds and tests run in their own cgroup under P. These
> > builds/tests continuously come and go.
> >
> > This service continuously monitors all the builds/tests running and
> > may kill some based on some criteria which includes memory usage.
> > However the memory usage is nondeterministic and killing a specific
> > build/test may not really free memory if most of the memory charged to
> > it is from shared build utilities.
>
> That doesn't sound too unusual. So, one saving grace here is that the memory
> pressure in the stressed cgroup should trigger reclaim of the shared memory
> which will be likely picked up by someone else, hopefully, under less memory
> pressure. Can you give more concerete details? ie. describe a failing
> scenario with actual ballpark memory numbers?

Mina, can you please provide details requested by Tejun?

>
> FWIW, at least from generic resource constrol standpoint, I think it may
> make sense to have a way to escape certain resources to an ancestor for
> shared resources provided that we can come up with a sane interface.
>
> Thanks.
>
> --
> tejun

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Tue, Jul 12, 2022 at 11:11:25AM -0700, Shakeel Butt wrote:
> Ccing Mina who actually worked on upstreaming this. See [1] for
> previous discussion and more use-cases.
> 
> [1] https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/

Doesn't look like that it landed upstream?

For bpf side we're thinking of something similar.
We cannot do memcg= mount option, of course.
Instead memcg path or FD will passed to bpf side to be used later.
So the user can select a memcg instead of taking it from current.

Yafang,
I'm assuming you're working on something like this?

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Yafang Shao]

On Wed, Jul 13, 2022 at 2:43 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Jul 12, 2022 at 11:11:25AM -0700, Shakeel Butt wrote:
> > Ccing Mina who actually worked on upstreaming this. See [1] for
> > previous discussion and more use-cases.
> >
> > [1] https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/
>
> Doesn't look like that it landed upstream?
>
> For bpf side we're thinking of something similar.
> We cannot do memcg= mount option, of course.
> Instead memcg path or FD will passed to bpf side to be used later.
> So the user can select a memcg instead of taking it from current.
>
> Yafang,
> I'm assuming you're working on something like this?

Yes, I'm working on it. I will post it once it is ready, but probably
not shortly.

-- 
Regards
Yafang

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Mina Almasry]

On Tue, Jul 12, 2022 at 11:11 AM Shakeel Butt <shakeelb@google.com> wrote:
>
> Ccing Mina who actually worked on upstreaming this. See [1] for
> previous discussion and more use-cases.
>
> [1] https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/
>
> On Tue, Jul 12, 2022 at 10:36 AM Tejun Heo <tj@kernel.org> wrote:
> >
> > Hello,
> >
> > On Tue, Jul 12, 2022 at 10:26:22AM -0700, Shakeel Butt wrote:
> > > One use-case we have is a build & test service which runs independent
> > > builds and tests but all the build utilities (compiler, linker,
> > > libraries) are shared between those builds and tests.
> > >
> > > In terms of topology, the service has a top level cgroup (P) and all
> > > independent builds and tests run in their own cgroup under P. These
> > > builds/tests continuously come and go.
> > >
> > > This service continuously monitors all the builds/tests running and
> > > may kill some based on some criteria which includes memory usage.
> > > However the memory usage is nondeterministic and killing a specific
> > > build/test may not really free memory if most of the memory charged to
> > > it is from shared build utilities.
> >
> > That doesn't sound too unusual. So, one saving grace here is that the memory
> > pressure in the stressed cgroup should trigger reclaim of the shared memory
> > which will be likely picked up by someone else, hopefully, under less memory
> > pressure. Can you give more concerete details? ie. describe a failing
> > scenario with actual ballpark memory numbers?
>
> Mina, can you please provide details requested by Tejun?
>

As far as I am aware the builds/tests service Shakeel mentioned is a
theoretical use case we're considering, but the actual use cases we're
running are the 3 I listed in my cover letter in my original proposal:

https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/

Still, the use case Shakeel is talking about is almost identical to
use case #2 in that proposal:
"Our infrastructure has large meta jobs such as kubernetes which spawn
multiple subtasks which share a tmpfs mount. These jobs and its
subtasks use that tmpfs mount for various purposes such as data
sharing or persistent data between the subtask restarts. In kubernetes
terminology, the meta job is similar to pods and subtasks are
containers under pods. We want the shared memory to be
deterministically charged to the kubernetes's pod and independent to
the lifetime of containers under the pod."

To run such a job we do the following:

- We setup a hierarchy like so:
                   pod_container
                  /           |                 \
container_a    container_b     container_c

- We set up a tmpfs mount with memcg= pod_container. This instructs
the kernel to charge all of this tmpfs user data to pod_container,
instead of the memcg of the task which faults in the shared memory.

- We set up the pod_container.max to be the maximum amount of memory
allowed to the _entire_ job.

- We set up container_a.max, container_b.max, and container_c.max to
be the limit of each of sub-tasks a, b, and c respectively, not
including the shared memory, which is allocated via the tmpfs mount
and charged directly to pod_container.


For some rough numbers, you can imagine a scenario:

tmpfs memcg=pod_container,size=100MB

                                 pod_container.max=130MB
                    /                           |
             \
container_a.max=10MB    container_b.max=20MB    container_c.max=30MB


Thanks to memcg=pod_container, neither tasks a, b, and c are charged
for the shared memory, so they can stay within their 10MB, 20MB, and
30MB limits respectively. This gives us fine grained control to
deterministically charge the shared memory and apply limits on the
memory usage of the individual sub-tasks and the overall amount of
memory the entire pod should consume.

For transparency's sake, this is Johannes's comments on the API:
https://lore.kernel.org/linux-mm/YZvppKvUPTIytM%2Fc@cmpxchg.org/

As Tejun puts it:

"it may make sense to have a way to escape certain resources to an ancestor for
shared resources provided that we can come up with a sane interface"

The interface Johannes has opted for is to reparent memory to the
common ancestor _when it is accessed by a task in another memcg_. This
doesn't work for us for a few reasons, one of which in the example
above container_a may get charged for all the 100MB of shared memory
if it's the unlucky task that faults in all the shared memory.


> >
> > FWIW, at least from generic resource constrol standpoint, I think it may
> > make sense to have a way to escape certain resources to an ancestor for
> > shared resources provided that we can come up with a sane interface.
> >
> > Thanks.
> >
> > --
> > tejun

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Tejun Heo]

Hello, Michal.

On Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote:
> > Agreed. That's why I don't like reparenting.
> > Reparenting just reparent the charged pages and then redirect the new
> > charge, but can't reparents the 'limit' of the original memcg.
> > So it is a risk if the original memcg is still being charged. We have
> > to forbid the destruction of the original memcg.
> 
> yes, I was toying with an idea like that. I guess we really want a
> measure to keep cgroups around if they are bound to a resource which is
> sticky itself. I am not sure how many other resources like BPF (aka
> module like) we already do charge for memcg but considering the
> potential memory consumption just reparenting will not help in general
> case I am afraid.

I think the solution here is an extra cgroup layering to represent
persistent resource tracking. In systemd-speak, a service should have a
cgroup representing a persistent service type and a cgroup representing the
current running instance. This way, the user (or system agent) can clearly
distinguish all resources that have ever been attributed to the service and
the resources that are accounted to the current instance while also giving
visibility into residual resources for services that are no longer running.

This gives userspace control over what to track for how long and also fits
what the kernel can do in terms of resource tracking. If we try to do
something smart from kernel side, there are cases which are inherently
insolvable. e.g. if a service instance creates tmpfs / shmem / whawtever and
leaves it pinned one way or another and then exits, and there's no one who
actively accessed it afterwards, there is no userland visible entity we can
reasonably attribute that memory to other than the parent cgroup.

Thanks.

-- 
tejun

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Michal Hocko]

On Tue 12-07-22 06:24:20, Tejun Heo wrote:
> Hello, Michal.
> 
> On Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote:
> > > Agreed. That's why I don't like reparenting.
> > > Reparenting just reparent the charged pages and then redirect the new
> > > charge, but can't reparents the 'limit' of the original memcg.
> > > So it is a risk if the original memcg is still being charged. We have
> > > to forbid the destruction of the original memcg.
> > 
> > yes, I was toying with an idea like that. I guess we really want a
> > measure to keep cgroups around if they are bound to a resource which is
> > sticky itself. I am not sure how many other resources like BPF (aka
> > module like) we already do charge for memcg but considering the
> > potential memory consumption just reparenting will not help in general
> > case I am afraid.
> 
> I think the solution here is an extra cgroup layering to represent
> persistent resource tracking. In systemd-speak, a service should have a
> cgroup representing a persistent service type and a cgroup representing the
> current running instance. This way, the user (or system agent) can clearly
> distinguish all resources that have ever been attributed to the service and
> the resources that are accounted to the current instance while also giving
> visibility into residual resources for services that are no longer running.

Just to make sure I follow what you mean here. You are suggesting that
the cgroup manager would ensure that there will be a parent responsible
for the resource and that cgroup will not go away as long as there are
resources (well modulo admin interferese which is not really interesting
usecase).

I do agree that this approach would be easier from the kernel
perspective. It is also more error prone because some resources might be
so runtime specific that it is hard to predict and configure them in
advance. My thinking about "sticky" cgroups was based on the reference
count of approach when the kernel knows that the resource requires some
sort of tear down which is not process life scoped and would take a
reference on the cgroup to keep it alive. I can see a concern that this
can get quite subtle in many cases though.

> This gives userspace control over what to track for how long and also fits
> what the kernel can do in terms of resource tracking. If we try to do
> something smart from kernel side, there are cases which are inherently
> insolvable. e.g. if a service instance creates tmpfs / shmem / whawtever and
> leaves it pinned one way or another and then exits, and there's no one who
> actively accessed it afterwards, there is no userland visible entity we can
> reasonably attribute that memory to other than the parent cgroup.

yeah, tmpfs would be another example which is even more complex because
a single file can "belong" to different memcgs.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Roman Gushchin]

On Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote:
> On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> > On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
> [...]
> > > > Roman already sent reparenting fix:
> > > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
> > >
> > > Reparenting is nice but not a silver bullet. Consider a shallow
> > > hierarchy where the charging happens in the first level under the root
> > > memcg. Reparenting to the root is just pushing everything under the
> > > system resources category.
> > >
> > 
> > Agreed. That's why I don't like reparenting.
> > Reparenting just reparent the charged pages and then redirect the new
> > charge, but can't reparents the 'limit' of the original memcg.
> > So it is a risk if the original memcg is still being charged. We have
> > to forbid the destruction of the original memcg.

I agree, I also don't like reparenting for !kmem case. For kmem (and *maybe*
bpf maps is an exception), I don't think there is a better choice.

> yes, I was toying with an idea like that. I guess we really want a
> measure to keep cgroups around if they are bound to a resource which is
> sticky itself. I am not sure how many other resources like BPF (aka
> module like) we already do charge for memcg but considering the
> potential memory consumption just reparenting will not help in general
> case I am afraid.

Well, then we have to make these objects a first-class citizens in cgroup API,
like processes. E.g. introduce cgroup.bpf.maps, cgroup.mounts.tmpfs etc.
I easily can see some value here, but it's a big API change.

With the current approach when a bpf map pins a memory cgroup of the creator
process (which I think is completely transparent for most bpf users), I don't
think preventing the deletion of a such cgroup is possible. It will break too
many things.

But honestly I don't see why userspace can't handle it. If there is a cgroup which
contains shared bpf maps, why would it delete it? It's a weird use case, I don't
think we have to optimize for it. Also, we do a ton of optimizations for live
cgroups (e.g. css refcounting being percpu) which are not working for a deleted
cgroup. So noone really should expect any properties from dying cgroups.

Thanks!

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Yafang Shao]

On Wed, Jul 13, 2022 at 10:39 AM Roman Gushchin
<roman.gushchin@linux.dev> wrote:
>
> On Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote:
> > On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> > > On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
> > [...]
> > > > > Roman already sent reparenting fix:
> > > > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
> > > >
> > > > Reparenting is nice but not a silver bullet. Consider a shallow
> > > > hierarchy where the charging happens in the first level under the root
> > > > memcg. Reparenting to the root is just pushing everything under the
> > > > system resources category.
> > > >
> > >
> > > Agreed. That's why I don't like reparenting.
> > > Reparenting just reparent the charged pages and then redirect the new
> > > charge, but can't reparents the 'limit' of the original memcg.
> > > So it is a risk if the original memcg is still being charged. We have
> > > to forbid the destruction of the original memcg.
>
> I agree, I also don't like reparenting for !kmem case. For kmem (and *maybe*
> bpf maps is an exception), I don't think there is a better choice.
>
> > yes, I was toying with an idea like that. I guess we really want a
> > measure to keep cgroups around if they are bound to a resource which is
> > sticky itself. I am not sure how many other resources like BPF (aka
> > module like) we already do charge for memcg but considering the
> > potential memory consumption just reparenting will not help in general
> > case I am afraid.
>
> Well, then we have to make these objects a first-class citizens in cgroup API,
> like processes. E.g. introduce cgroup.bpf.maps, cgroup.mounts.tmpfs etc.
> I easily can see some value here, but it's a big API change.
>
> With the current approach when a bpf map pins a memory cgroup of the creator
> process (which I think is completely transparent for most bpf users), I don't
> think preventing the deletion of a such cgroup is possible. It will break too
> many things.
>
> But honestly I don't see why userspace can't handle it. If there is a cgroup which
> contains shared bpf maps, why would it delete it? It's a weird use case, I don't
> think we have to optimize for it. Also, we do a ton of optimizations for live
> cgroups (e.g. css refcounting being percpu) which are not working for a deleted
> cgroup. So noone really should expect any properties from dying cgroups.
>

I think we have discussed why the user can't handle it easily.
Actually It's NOT a weird use case if you are a k8s user.  (Of course
it may seem weird to the systemd user, but unfortunately systemd
doesn't rule the whole world. )
I have told you that it is not reasonable to refuse a containerized
process to pin bpf programs, but if you are not familiar with k8s, it
is not easy to explain clearly why it is a trouble for deployment.
But I can try to explain to you from a *systemd user's* perspective.

                   bpf-memcg                       (must be persistent)
                  /                \
  bpf-foo-memcg       bpf-bar-memcg   (must be persistent, and limit here)
-------------------------------------------------------
           /                              \
    bpf-foo pod              bpf-bar pod    (being created and
destroyed, but not limited)

I assume the above hierarchy is what you expect.
But you know, in the k8s environment, everything is pod-based, that
means if we use the above hierarchy in the k8s environment, the k8s's
limiting, monitoring, debugging must be changed consequently.  That
means it may be a fullstack change in k8s, a great refactor.

So below hierarchy is a reasonable solution,
                                          bpf-memcg
                                                |
  bpf-foo pod                    bpf-foo-memcg     (limited)
       /          \                                /
(charge)     (not-charged)      (charged)
proc-foo                     bpf-foo

And then keep the bpf-memgs persistent.

-- 
Regards
Yafang

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Tejun Heo]

Hello,

On Wed, Jul 13, 2022 at 10:24:05PM +0800, Yafang Shao wrote:
> I have told you that it is not reasonable to refuse a containerized
> process to pin bpf programs, but if you are not familiar with k8s, it
> is not easy to explain clearly why it is a trouble for deployment.
> But I can try to explain to you from a *systemd user's* perspective.

The way systemd currently sets up cgroup hierarchy doesn't work for
persistent per-service resource tracking. It needs to introduce an extra
layer for that which woudl be a significant change for systemd too.

> I assume the above hierarchy is what you expect.
> But you know, in the k8s environment, everything is pod-based, that
> means if we use the above hierarchy in the k8s environment, the k8s's
> limiting, monitoring, debugging must be changed consequently.  That
> means it may be a fullstack change in k8s, a great refactor.
> 
> So below hierarchy is a reasonable solution,
>                                           bpf-memcg
>                                                 |
>   bpf-foo pod                    bpf-foo-memcg     (limited)
>        /          \                                /
> (charge)     (not-charged)      (charged)
> proc-foo                     bpf-foo
> 
> And then keep the bpf-memgs persistent.

It looks like you draw the diagram with variable width font and it's
difficult to tell what you're trying to say. That said, I don't think the
argument you're making is a good one in general. The topic at hand is future
architectural direction in handling shared resources, which was never well
supported before. ie. We're not talking about breaking existing behaviors.

We don't want to architect kernel features to suit the expectations of one
particular application. It has to be longer term than that and it can't be
an one way road. Sometimes the kernel adapts to existing applications
because the expectations make sense. At other times, kernel takes a
direction which may require some work from applications to use new
capabilities because that makes more sense in the long term.

Let's keep the discussion more focused on technical merits.

Thanks.

-- 
tejun

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Yafang Shao]

On Thu, Jul 14, 2022 at 12:24 AM Tejun Heo <tj@kernel.org> wrote:
>
> Hello,
>
> On Wed, Jul 13, 2022 at 10:24:05PM +0800, Yafang Shao wrote:
> > I have told you that it is not reasonable to refuse a containerized
> > process to pin bpf programs, but if you are not familiar with k8s, it
> > is not easy to explain clearly why it is a trouble for deployment.
> > But I can try to explain to you from a *systemd user's* perspective.
>
> The way systemd currently sets up cgroup hierarchy doesn't work for
> persistent per-service resource tracking. It needs to introduce an extra
> layer for that which woudl be a significant change for systemd too.
>
> > I assume the above hierarchy is what you expect.
> > But you know, in the k8s environment, everything is pod-based, that
> > means if we use the above hierarchy in the k8s environment, the k8s's
> > limiting, monitoring, debugging must be changed consequently.  That
> > means it may be a fullstack change in k8s, a great refactor.
> >
> > So below hierarchy is a reasonable solution,
> >                                           bpf-memcg
> >                                                 |
> >   bpf-foo pod                    bpf-foo-memcg     (limited)
> >        /          \                                /
> > (charge)     (not-charged)      (charged)
> > proc-foo                     bpf-foo
> >
> > And then keep the bpf-memgs persistent.
>
> It looks like you draw the diagram with variable width font and it's
> difficult to tell what you're trying to say.

Maybe below diagram is more clear to you ?
                                          bpf-memcg
                                                |
  bpf-foo pod                    bpf-foo-memcg     (limited)
       /          \                                /
(charge)     (not-charged)      (charged)
   |                         \                /
   |                          \              /
proc-foo                   bpf-foo

bpf-foo is loaded by process-foo, but it is not charge to the bpf-foo
pod, while it is remotely charge to bpf-foo-memcg.

>  That said, I don't think the
> argument you're making is a good one in general. The topic at hand is future
> architectural direction in handling shared resources, which was never well
> supported before. ie. We're not talking about breaking existing behaviors.
>
> We don't want to architect kernel features to suit the expectations of one
> particular application. It has to be longer term than that and it can't be
> an one way road. Sometimes the kernel adapts to existing applications
> because the expectations make sense. At other times, kernel takes a
> direction which may require some work from applications to use new
> capabilities because that makes more sense in the long term.
>

The shared resources or remote charge is not a new issue, see also
task->active_memcg. The case (map->memcg or map->objcg) we are
handling now is similar with task->active_memcg. If we want to make it
generic, I think we can start with task->active_memcg.

To make it generic, I have some superficial thinking on the cgroup side.
1) Can we extend the cgroup tree to cgroup graph ?
2) Can we extend the cgroup from process-based (cgroup.procs) to
resource-based (cgroup.resources) ?

Regarding question 1).
Originally the charge direction is vertical,  looks like a tree, as below,
      parent
         ^
          |
       cgroup

But after the task->active_memcg, there's a newly horizontal charge, as below,
      parent
         ^
          |
       cgroup  ---->  friend

They will have a same ancestor, so finally it looks like a graph,
              ancestor
              /             \
           ...               ...
           /                  \
       cgroup  ----  friend


Regarding question 2).
The lifecycle of a leaf cgroup is same with the processes inside it.
But after the remote charge been introduced, the lifecycle of a leaf
cgroup may be same with the process in other cgroups. That said, it is
not sufficient to be treated as process-based, because what it really
care about is the resources, so may be we should extend it to
resource-based.

> Let's keep the discussion more focused on technical merits.
>
> Thanks.
>
> --
> tejun



-- 
Regards
Yafang

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Yosry Ahmed]

On Tue, Jul 12, 2022 at 7:39 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
>
> On Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote:
> > On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> > > On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
> > [...]
> > > > > Roman already sent reparenting fix:
> > > > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
> > > >
> > > > Reparenting is nice but not a silver bullet. Consider a shallow
> > > > hierarchy where the charging happens in the first level under the root
> > > > memcg. Reparenting to the root is just pushing everything under the
> > > > system resources category.
> > > >
> > >
> > > Agreed. That's why I don't like reparenting.
> > > Reparenting just reparent the charged pages and then redirect the new
> > > charge, but can't reparents the 'limit' of the original memcg.
> > > So it is a risk if the original memcg is still being charged. We have
> > > to forbid the destruction of the original memcg.
>
> I agree, I also don't like reparenting for !kmem case. For kmem (and *maybe*
> bpf maps is an exception), I don't think there is a better choice.
>
> > yes, I was toying with an idea like that. I guess we really want a
> > measure to keep cgroups around if they are bound to a resource which is
> > sticky itself. I am not sure how many other resources like BPF (aka
> > module like) we already do charge for memcg but considering the
> > potential memory consumption just reparenting will not help in general
> > case I am afraid.
>
> Well, then we have to make these objects a first-class citizens in cgroup API,
> like processes. E.g. introduce cgroup.bpf.maps, cgroup.mounts.tmpfs etc.
> I easily can see some value here, but it's a big API change.
>
> With the current approach when a bpf map pins a memory cgroup of the creator
> process (which I think is completely transparent for most bpf users), I don't
> think preventing the deletion of a such cgroup is possible. It will break too
> many things.
>
> But honestly I don't see why userspace can't handle it. If there is a cgroup which
> contains shared bpf maps, why would it delete it? It's a weird use case, I don't
> think we have to optimize for it. Also, we do a ton of optimizations for live
> cgroups (e.g. css refcounting being percpu) which are not working for a deleted
> cgroup. So noone really should expect any properties from dying cgroups.
>

Just a random thought here, and I can easily be wrong (and this can
easily be the wrong thread for this), but if we introduce a more
generic concept to generally tie a resource explicitly to a cgroup
(tmpfs, bpf maps, etc) using cgroupfs interfaces, and then prevent the
cgroup from being deleted unless the resource is freed or moved to a
different cgroup?

This would be optional, so the current status quo is maintainable, but
also gives flexibility to admins to assign resources to cgroups to
make sure nothing is ( unaccounted / accounted to a zombie memcg /
reparented to an unrelated parent ). This might be too fine-grained to
be practical but I just thought it might be useful. We will also need
to define an OOM behavior for such resources. Things like bpf maps
will be unreclaimable, but tmpfs memory can be swapped out.

I think this also partially addresses Johannes's concerns that the
memcg= mount option uses file system mounts to create shareable
resource domains outside of the cgroup hierarchy.

> Thanks!
>

cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Michal Hocko]

On Mon 18-07-22 10:55:59, Yosry Ahmed wrote:
> On Tue, Jul 12, 2022 at 7:39 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> >
> > On Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote:
> > > On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> > > > On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
> > > [...]
> > > > > > Roman already sent reparenting fix:
> > > > > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
> > > > >
> > > > > Reparenting is nice but not a silver bullet. Consider a shallow
> > > > > hierarchy where the charging happens in the first level under the root
> > > > > memcg. Reparenting to the root is just pushing everything under the
> > > > > system resources category.
> > > > >
> > > >
> > > > Agreed. That's why I don't like reparenting.
> > > > Reparenting just reparent the charged pages and then redirect the new
> > > > charge, but can't reparents the 'limit' of the original memcg.
> > > > So it is a risk if the original memcg is still being charged. We have
> > > > to forbid the destruction of the original memcg.
> >
> > I agree, I also don't like reparenting for !kmem case. For kmem (and *maybe*
> > bpf maps is an exception), I don't think there is a better choice.
> >
> > > yes, I was toying with an idea like that. I guess we really want a
> > > measure to keep cgroups around if they are bound to a resource which is
> > > sticky itself. I am not sure how many other resources like BPF (aka
> > > module like) we already do charge for memcg but considering the
> > > potential memory consumption just reparenting will not help in general
> > > case I am afraid.
> >
> > Well, then we have to make these objects a first-class citizens in cgroup API,
> > like processes. E.g. introduce cgroup.bpf.maps, cgroup.mounts.tmpfs etc.
> > I easily can see some value here, but it's a big API change.
> >
> > With the current approach when a bpf map pins a memory cgroup of the creator
> > process (which I think is completely transparent for most bpf users), I don't
> > think preventing the deletion of a such cgroup is possible. It will break too
> > many things.
> >
> > But honestly I don't see why userspace can't handle it. If there is a cgroup which
> > contains shared bpf maps, why would it delete it? It's a weird use case, I don't
> > think we have to optimize for it. Also, we do a ton of optimizations for live
> > cgroups (e.g. css refcounting being percpu) which are not working for a deleted
> > cgroup. So noone really should expect any properties from dying cgroups.
> >
> 
> Just a random thought here, and I can easily be wrong (and this can
> easily be the wrong thread for this), but if we introduce a more
> generic concept to generally tie a resource explicitly to a cgroup
> (tmpfs, bpf maps, etc) using cgroupfs interfaces, and then prevent the
> cgroup from being deleted unless the resource is freed or moved to a
> different cgroup?

My understanding is that Tejun would prefer a user space defined policy
by a proper layering. And I would tend to agree that this is less prone
to corner cases.

Anyway, how would you envision such an interface?

> This would be optional, so the current status quo is maintainable, but
> also gives flexibility to admins to assign resources to cgroups to
> make sure nothing is ( unaccounted / accounted to a zombie memcg /
> reparented to an unrelated parent ). This might be too fine-grained to
> be practical but I just thought it might be useful. We will also need
> to define an OOM behavior for such resources. Things like bpf maps
> will be unreclaimable, but tmpfs memory can be swapped out.

Keep in mind that the swap is a shared resource in itself. So tmpfs is
essentially a sticky resource as well. A tmpfs file is not bound to any
proces life time the same way BPF program is. You might need less
priviledges to remove a file but in principle they are consuming
resources without any explicit owner.
-- 
Michal Hocko
SUSE Labs

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Yosry Ahmed]

On Tue, Jul 19, 2022 at 4:30 AM Michal Hocko <mhocko@suse.com> wrote:
>
> On Mon 18-07-22 10:55:59, Yosry Ahmed wrote:
> > On Tue, Jul 12, 2022 at 7:39 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> > >
> > > On Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote:
> > > > On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> > > > > On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
> > > > [...]
> > > > > > > Roman already sent reparenting fix:
> > > > > > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
> > > > > >
> > > > > > Reparenting is nice but not a silver bullet. Consider a shallow
> > > > > > hierarchy where the charging happens in the first level under the root
> > > > > > memcg. Reparenting to the root is just pushing everything under the
> > > > > > system resources category.
> > > > > >
> > > > >
> > > > > Agreed. That's why I don't like reparenting.
> > > > > Reparenting just reparent the charged pages and then redirect the new
> > > > > charge, but can't reparents the 'limit' of the original memcg.
> > > > > So it is a risk if the original memcg is still being charged. We have
> > > > > to forbid the destruction of the original memcg.
> > >
> > > I agree, I also don't like reparenting for !kmem case. For kmem (and *maybe*
> > > bpf maps is an exception), I don't think there is a better choice.
> > >
> > > > yes, I was toying with an idea like that. I guess we really want a
> > > > measure to keep cgroups around if they are bound to a resource which is
> > > > sticky itself. I am not sure how many other resources like BPF (aka
> > > > module like) we already do charge for memcg but considering the
> > > > potential memory consumption just reparenting will not help in general
> > > > case I am afraid.
> > >
> > > Well, then we have to make these objects a first-class citizens in cgroup API,
> > > like processes. E.g. introduce cgroup.bpf.maps, cgroup.mounts.tmpfs etc.
> > > I easily can see some value here, but it's a big API change.
> > >
> > > With the current approach when a bpf map pins a memory cgroup of the creator
> > > process (which I think is completely transparent for most bpf users), I don't
> > > think preventing the deletion of a such cgroup is possible. It will break too
> > > many things.
> > >
> > > But honestly I don't see why userspace can't handle it. If there is a cgroup which
> > > contains shared bpf maps, why would it delete it? It's a weird use case, I don't
> > > think we have to optimize for it. Also, we do a ton of optimizations for live
> > > cgroups (e.g. css refcounting being percpu) which are not working for a deleted
> > > cgroup. So noone really should expect any properties from dying cgroups.
> > >
> >
> > Just a random thought here, and I can easily be wrong (and this can
> > easily be the wrong thread for this), but if we introduce a more
> > generic concept to generally tie a resource explicitly to a cgroup
> > (tmpfs, bpf maps, etc) using cgroupfs interfaces, and then prevent the
> > cgroup from being deleted unless the resource is freed or moved to a
> > different cgroup?
>
> My understanding is that Tejun would prefer a user space defined policy
> by a proper layering. And I would tend to agree that this is less prone
> to corner cases.
>
> Anyway, how would you envision such an interface?

I imagine something like cgroup.sticky.[bpf/tmpfs/..] (I suck at naming things).

The file can contain a list of bpf map ids or tmpfs inode ids or mount
paths. You can write a new id/path to the file to add one, or read the
file to see a list of them. Basically very similar semantics to
cgroup.procs. Instead of processes, we have different types of sticky
resources here that usually outlive processes. The charging of such
resources would be deterministically attributed to this cgroup
(instead of the cgroup of the process that created the map or touched
the tmpfs file first).

Since the system admin has explicitly attributed these resources to
this cgroup, it makes sense that the cgroup cannot be deleted as long
as these resources exist and are charged to it, similar to
cgroup.procs. This also addresses some of the zombie cgroups problems.

The obvious question is: to maintain the current behavior, bpf maps
and tmpfs mounts will be by default initially charged the same way as
today. bpf maps for the cgroup of the process that created them, and
tmpfs pages on first touch basis. How do we move their charging after
their creation in the current way to a cgroup.sticky file?

For things like bpf maps, it should be relatively simple to move
charges the same way we do when we move processes, because the bpf map
is by default charged to one memcg. For tmpfs, it would be challenging
to move the charges because pages could be individually attributed to
different cgroups already. For this, we can impose a (imo reasonable)
restriction that for tmpfs (and similar resources that are currently
not attributed to a single cgroup), that you can only add a tmpfs
mount to cgroup.sticky.tmpfs for the first time if no pages have been
charged yet (no files created). Once the tmpfs mount lives in any
cgroup.sticky.tmpfs file, we know that it is charged to one cgroup,
and we can move the charges more easily.

The system admin would basically mount the tmpfs directory and then
directly write it to a cgroup.sticky.tmpfs file. For that point
onwards, all tmpfs pages will be charged to that cgroup, and they need
to be freed or moved before the cgroup can be removed.

I could be missing something here, but I imagine such an interface(s)
would address both the bpf progs/maps charging concerns, and our
previous memcg= mount attempts. Please correct me if I am wrong.

>
> > This would be optional, so the current status quo is maintainable, but
> > also gives flexibility to admins to assign resources to cgroups to
> > make sure nothing is ( unaccounted / accounted to a zombie memcg /
> > reparented to an unrelated parent ). This might be too fine-grained to
> > be practical but I just thought it might be useful. We will also need
> > to define an OOM behavior for such resources. Things like bpf maps
> > will be unreclaimable, but tmpfs memory can be swapped out.
>
> Keep in mind that the swap is a shared resource in itself. So tmpfs is
> essentially a sticky resource as well. A tmpfs file is not bound to any
> proces life time the same way BPF program is. You might need less
> priviledges to remove a file but in principle they are consuming
> resources without any explicit owner.

I fully agree, which is exactly why I am suggesting having a defined
way to handle such "sticky" resources that outlive processes.
Currently cgroups operate in terms of processes and this can be a
limitation for such resources.

> --
> Michal Hocko
> SUSE Labs

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Yosry Ahmed]

+Mina Almasry

On Tue, Jul 19, 2022 at 11:00 AM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Tue, Jul 19, 2022 at 4:30 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Mon 18-07-22 10:55:59, Yosry Ahmed wrote:
> > > On Tue, Jul 12, 2022 at 7:39 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> > > >
> > > > On Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote:
> > > > > On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> > > > > > On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
> > > > > [...]
> > > > > > > > Roman already sent reparenting fix:
> > > > > > > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
> > > > > > >
> > > > > > > Reparenting is nice but not a silver bullet. Consider a shallow
> > > > > > > hierarchy where the charging happens in the first level under the root
> > > > > > > memcg. Reparenting to the root is just pushing everything under the
> > > > > > > system resources category.
> > > > > > >
> > > > > >
> > > > > > Agreed. That's why I don't like reparenting.
> > > > > > Reparenting just reparent the charged pages and then redirect the new
> > > > > > charge, but can't reparents the 'limit' of the original memcg.
> > > > > > So it is a risk if the original memcg is still being charged. We have
> > > > > > to forbid the destruction of the original memcg.
> > > >
> > > > I agree, I also don't like reparenting for !kmem case. For kmem (and *maybe*
> > > > bpf maps is an exception), I don't think there is a better choice.
> > > >
> > > > > yes, I was toying with an idea like that. I guess we really want a
> > > > > measure to keep cgroups around if they are bound to a resource which is
> > > > > sticky itself. I am not sure how many other resources like BPF (aka
> > > > > module like) we already do charge for memcg but considering the
> > > > > potential memory consumption just reparenting will not help in general
> > > > > case I am afraid.
> > > >
> > > > Well, then we have to make these objects a first-class citizens in cgroup API,
> > > > like processes. E.g. introduce cgroup.bpf.maps, cgroup.mounts.tmpfs etc.
> > > > I easily can see some value here, but it's a big API change.
> > > >
> > > > With the current approach when a bpf map pins a memory cgroup of the creator
> > > > process (which I think is completely transparent for most bpf users), I don't
> > > > think preventing the deletion of a such cgroup is possible. It will break too
> > > > many things.
> > > >
> > > > But honestly I don't see why userspace can't handle it. If there is a cgroup which
> > > > contains shared bpf maps, why would it delete it? It's a weird use case, I don't
> > > > think we have to optimize for it. Also, we do a ton of optimizations for live
> > > > cgroups (e.g. css refcounting being percpu) which are not working for a deleted
> > > > cgroup. So noone really should expect any properties from dying cgroups.
> > > >
> > >
> > > Just a random thought here, and I can easily be wrong (and this can
> > > easily be the wrong thread for this), but if we introduce a more
> > > generic concept to generally tie a resource explicitly to a cgroup
> > > (tmpfs, bpf maps, etc) using cgroupfs interfaces, and then prevent the
> > > cgroup from being deleted unless the resource is freed or moved to a
> > > different cgroup?
> >
> > My understanding is that Tejun would prefer a user space defined policy
> > by a proper layering. And I would tend to agree that this is less prone
> > to corner cases.
> >
> > Anyway, how would you envision such an interface?
>
> I imagine something like cgroup.sticky.[bpf/tmpfs/..] (I suck at naming things).
>
> The file can contain a list of bpf map ids or tmpfs inode ids or mount
> paths. You can write a new id/path to the file to add one, or read the
> file to see a list of them. Basically very similar semantics to
> cgroup.procs. Instead of processes, we have different types of sticky
> resources here that usually outlive processes. The charging of such
> resources would be deterministically attributed to this cgroup
> (instead of the cgroup of the process that created the map or touched
> the tmpfs file first).
>
> Since the system admin has explicitly attributed these resources to
> this cgroup, it makes sense that the cgroup cannot be deleted as long
> as these resources exist and are charged to it, similar to
> cgroup.procs. This also addresses some of the zombie cgroups problems.
>
> The obvious question is: to maintain the current behavior, bpf maps
> and tmpfs mounts will be by default initially charged the same way as
> today. bpf maps for the cgroup of the process that created them, and
> tmpfs pages on first touch basis. How do we move their charging after
> their creation in the current way to a cgroup.sticky file?
>
> For things like bpf maps, it should be relatively simple to move
> charges the same way we do when we move processes, because the bpf map
> is by default charged to one memcg. For tmpfs, it would be challenging
> to move the charges because pages could be individually attributed to
> different cgroups already. For this, we can impose a (imo reasonable)
> restriction that for tmpfs (and similar resources that are currently
> not attributed to a single cgroup), that you can only add a tmpfs
> mount to cgroup.sticky.tmpfs for the first time if no pages have been
> charged yet (no files created). Once the tmpfs mount lives in any
> cgroup.sticky.tmpfs file, we know that it is charged to one cgroup,
> and we can move the charges more easily.
>
> The system admin would basically mount the tmpfs directory and then
> directly write it to a cgroup.sticky.tmpfs file. For that point
> onwards, all tmpfs pages will be charged to that cgroup, and they need
> to be freed or moved before the cgroup can be removed.
>
> I could be missing something here, but I imagine such an interface(s)
> would address both the bpf progs/maps charging concerns, and our
> previous memcg= mount attempts. Please correct me if I am wrong.
>
> >
> > > This would be optional, so the current status quo is maintainable, but
> > > also gives flexibility to admins to assign resources to cgroups to
> > > make sure nothing is ( unaccounted / accounted to a zombie memcg /
> > > reparented to an unrelated parent ). This might be too fine-grained to
> > > be practical but I just thought it might be useful. We will also need
> > > to define an OOM behavior for such resources. Things like bpf maps
> > > will be unreclaimable, but tmpfs memory can be swapped out.
> >
> > Keep in mind that the swap is a shared resource in itself. So tmpfs is
> > essentially a sticky resource as well. A tmpfs file is not bound to any
> > proces life time the same way BPF program is. You might need less
> > priviledges to remove a file but in principle they are consuming
> > resources without any explicit owner.
>
> I fully agree, which is exactly why I am suggesting having a defined
> way to handle such "sticky" resources that outlive processes.
> Currently cgroups operate in terms of processes and this can be a
> limitation for such resources.
>
> > --
> > Michal Hocko
> > SUSE Labs

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Mina Almasry]

On Tue, Jul 19, 2022 at 11:01 AM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Tue, Jul 19, 2022 at 4:30 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Mon 18-07-22 10:55:59, Yosry Ahmed wrote:
> > > On Tue, Jul 12, 2022 at 7:39 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> > > >
> > > > On Tue, Jul 12, 2022 at 11:52:11AM +0200, Michal Hocko wrote:
> > > > > On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> > > > > > On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
> > > > > [...]
> > > > > > > > Roman already sent reparenting fix:
> > > > > > > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
> > > > > > >
> > > > > > > Reparenting is nice but not a silver bullet. Consider a shallow
> > > > > > > hierarchy where the charging happens in the first level under the root
> > > > > > > memcg. Reparenting to the root is just pushing everything under the
> > > > > > > system resources category.
> > > > > > >
> > > > > >
> > > > > > Agreed. That's why I don't like reparenting.
> > > > > > Reparenting just reparent the charged pages and then redirect the new
> > > > > > charge, but can't reparents the 'limit' of the original memcg.
> > > > > > So it is a risk if the original memcg is still being charged. We have
> > > > > > to forbid the destruction of the original memcg.
> > > >
> > > > I agree, I also don't like reparenting for !kmem case. For kmem (and *maybe*
> > > > bpf maps is an exception), I don't think there is a better choice.
> > > >
> > > > > yes, I was toying with an idea like that. I guess we really want a
> > > > > measure to keep cgroups around if they are bound to a resource which is
> > > > > sticky itself. I am not sure how many other resources like BPF (aka
> > > > > module like) we already do charge for memcg but considering the
> > > > > potential memory consumption just reparenting will not help in general
> > > > > case I am afraid.
> > > >
> > > > Well, then we have to make these objects a first-class citizens in cgroup API,
> > > > like processes. E.g. introduce cgroup.bpf.maps, cgroup.mounts.tmpfs etc.
> > > > I easily can see some value here, but it's a big API change.
> > > >
> > > > With the current approach when a bpf map pins a memory cgroup of the creator
> > > > process (which I think is completely transparent for most bpf users), I don't
> > > > think preventing the deletion of a such cgroup is possible. It will break too
> > > > many things.
> > > >
> > > > But honestly I don't see why userspace can't handle it. If there is a cgroup which
> > > > contains shared bpf maps, why would it delete it? It's a weird use case, I don't
> > > > think we have to optimize for it. Also, we do a ton of optimizations for live
> > > > cgroups (e.g. css refcounting being percpu) which are not working for a deleted
> > > > cgroup. So noone really should expect any properties from dying cgroups.
> > > >
> > >
> > > Just a random thought here, and I can easily be wrong (and this can
> > > easily be the wrong thread for this), but if we introduce a more
> > > generic concept to generally tie a resource explicitly to a cgroup
> > > (tmpfs, bpf maps, etc) using cgroupfs interfaces, and then prevent the
> > > cgroup from being deleted unless the resource is freed or moved to a
> > > different cgroup?
> >
> > My understanding is that Tejun would prefer a user space defined policy
> > by a proper layering. And I would tend to agree that this is less prone
> > to corner cases.
> >
> > Anyway, how would you envision such an interface?
>
> I imagine something like cgroup.sticky.[bpf/tmpfs/..] (I suck at naming things).
>
> The file can contain a list of bpf map ids or tmpfs inode ids or mount
> paths. You can write a new id/path to the file to add one, or read the
> file to see a list of them. Basically very similar semantics to
> cgroup.procs. Instead of processes, we have different types of sticky
> resources here that usually outlive processes. The charging of such
> resources would be deterministically attributed to this cgroup
> (instead of the cgroup of the process that created the map or touched
> the tmpfs file first).
>
> Since the system admin has explicitly attributed these resources to
> this cgroup, it makes sense that the cgroup cannot be deleted as long
> as these resources exist and are charged to it, similar to
> cgroup.procs. This also addresses some of the zombie cgroups problems.
>
> The obvious question is: to maintain the current behavior, bpf maps
> and tmpfs mounts will be by default initially charged the same way as
> today. bpf maps for the cgroup of the process that created them, and
> tmpfs pages on first touch basis. How do we move their charging after
> their creation in the current way to a cgroup.sticky file?
>
> For things like bpf maps, it should be relatively simple to move
> charges the same way we do when we move processes, because the bpf map
> is by default charged to one memcg. For tmpfs, it would be challenging
> to move the charges because pages could be individually attributed to
> different cgroups already. For this, we can impose a (imo reasonable)
> restriction that for tmpfs (and similar resources that are currently
> not attributed to a single cgroup), that you can only add a tmpfs
> mount to cgroup.sticky.tmpfs for the first time if no pages have been
> charged yet (no files created). Once the tmpfs mount lives in any
> cgroup.sticky.tmpfs file, we know that it is charged to one cgroup,
> and we can move the charges more easily.
>
> The system admin would basically mount the tmpfs directory and then
> directly write it to a cgroup.sticky.tmpfs file. For that point
> onwards, all tmpfs pages will be charged to that cgroup, and they need
> to be freed or moved before the cgroup can be removed.
>
> I could be missing something here, but I imagine such an interface(s)
> would address both the bpf progs/maps charging concerns, and our
> previous memcg= mount attempts. Please correct me if I am wrong.
>
> >
> > > This would be optional, so the current status quo is maintainable, but
> > > also gives flexibility to admins to assign resources to cgroups to
> > > make sure nothing is ( unaccounted / accounted to a zombie memcg /
> > > reparented to an unrelated parent ). This might be too fine-grained to
> > > be practical but I just thought it might be useful. We will also need
> > > to define an OOM behavior for such resources. Things like bpf maps
> > > will be unreclaimable, but tmpfs memory can be swapped out.
> >
> > Keep in mind that the swap is a shared resource in itself. So tmpfs is
> > essentially a sticky resource as well. A tmpfs file is not bound to any
> > proces life time the same way BPF program is. You might need less
> > priviledges to remove a file but in principle they are consuming
> > resources without any explicit owner.
>
> I fully agree, which is exactly why I am suggesting having a defined
> way to handle such "sticky" resources that outlive processes.
> Currently cgroups operate in terms of processes and this can be a
> limitation for such resources.
>
> > --
> > Michal Hocko
> > SUSE Labs
>

An interface like cgroup.sticky.[bpf/tmpfs/..] would work for us
similar to tmpfs memcg= mount option. I would maybe rename it to
cgroup.charge_for.[bpf/tmpfs/etc] or something.

With regards to OOM, my proposal on this patchset is to return ENOSPC
to the caller if we hit the limit of the remote memcg and there is
nothing to kill:
https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/

There is some precedent to doing this in the kernel. If a hugetlb
allocation hits the hugetlb_cgroup limit, we return ENOSPC to the
caller (and SIGBUS in the charge path). The reason there being that we
don't support oom-kill or reclaim or swap for hugetlb pages.

I think it is also reasonable to prevent removing the memcg if there
is cgroup.charge_for.[bpf/tmpfs/etc] still alive. Currently we prevent
removing the memcg if there are tasks attached. So we can also prevent
removing the memcg if there are bpf/tmpfs charge sources pending.

Would love to hear from Tejun/Michal/Johannes if this is the interface
you're looking for.

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Tejun Heo]

Hello,

On Tue, Jul 19, 2022 at 11:46:41AM -0700, Mina Almasry wrote:
> An interface like cgroup.sticky.[bpf/tmpfs/..] would work for us
> similar to tmpfs memcg= mount option. I would maybe rename it to
> cgroup.charge_for.[bpf/tmpfs/etc] or something.

So, I'm not a fan because having this in cgroupfs would create the
expectation that these resources can be moved across cgroups dynamically
(and that's the only way the interface can be useful, right?). I'd much
prefer something a lot more minimal - e.g. temporarily allow assuming an
ancestor identity while creating a resource or sth along that line, and to
add something like that, I think we need pretty strong arguments for why it
can't be handled through cgroup layering in userspace.

Thanks.

-- 
tejun

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Yosry Ahmed]

On Tue, Jul 19, 2022 at 12:16 PM Tejun Heo <tj@kernel.org> wrote:
>
> Hello,
>
> On Tue, Jul 19, 2022 at 11:46:41AM -0700, Mina Almasry wrote:
> > An interface like cgroup.sticky.[bpf/tmpfs/..] would work for us
> > similar to tmpfs memcg= mount option. I would maybe rename it to
> > cgroup.charge_for.[bpf/tmpfs/etc] or something.
>
> So, I'm not a fan because having this in cgroupfs would create the
> expectation that these resources can be moved across cgroups dynamically
> (and that's the only way the interface can be useful, right?). I'd much

Is there a reason why these resources cannot be moved across cgroups
dynamically? The only scenario I imagine is if you already have tmpfs
mounted and files charged to different cgroups, but once you attribute
tmpfs to one cgroup.charge_for.tmpfs (or sticky,..), I assume that we
can dynamically move the resources, right?

In fact, is there a reason why we can't move the tmpfs charges in that
scenario as well? When we move processes we loop their pages tables
and move pages and their stats, is there a reason why we wouldn't be
able to do this with tmpfs mounts or bpf maps as well?


> prefer something a lot more minimal - e.g. temporarily allow assuming an
> ancestor identity while creating a resource or sth along that line, and to
> add something like that, I think we need pretty strong arguments for why it
> can't be handled through cgroup layering in userspace.
>
> Thanks.
>
> --
> tejun

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Tejun Heo]

On Tue, Jul 19, 2022 at 12:30:17PM -0700, Yosry Ahmed wrote:
> Is there a reason why these resources cannot be moved across cgroups
> dynamically? The only scenario I imagine is if you already have tmpfs
> mounted and files charged to different cgroups, but once you attribute
> tmpfs to one cgroup.charge_for.tmpfs (or sticky,..), I assume that we
> can dynamically move the resources, right?
> 
> In fact, is there a reason why we can't move the tmpfs charges in that
> scenario as well? When we move processes we loop their pages tables
> and move pages and their stats, is there a reason why we wouldn't be
> able to do this with tmpfs mounts or bpf maps as well?

Nothing is impossible but nothing is free as well. Moving charges around
traditionally caused a lot of headaches in the past and never became
reliable. There are inherent trade-offs here. You can make things more
dynamic usually by making hot paths more expensive or doing some
synchronization dancing which tends to be pretty hairy. People generally
don't wanna make hot paths slower, so we tend to end up with something
twisted which unfortunately turns out to be a headache in the long term.

In general, I'd rather keep resource associations as static as possible.
It's okay if we do something neat inside the kernel but if we create
userspace expectation that resources can be moved around dynamically, we'll
be stuck with that for a long time likely forfeiting future simplification /
optimization opportunities.

So, that's gonna be a fairly strong nack from my end.

Thanks.

-- 
tejun

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Yosry Ahmed]

On Tue, Jul 19, 2022 at 12:38 PM Tejun Heo <tj@kernel.org> wrote:
>
> On Tue, Jul 19, 2022 at 12:30:17PM -0700, Yosry Ahmed wrote:
> > Is there a reason why these resources cannot be moved across cgroups
> > dynamically? The only scenario I imagine is if you already have tmpfs
> > mounted and files charged to different cgroups, but once you attribute
> > tmpfs to one cgroup.charge_for.tmpfs (or sticky,..), I assume that we
> > can dynamically move the resources, right?
> >
> > In fact, is there a reason why we can't move the tmpfs charges in that
> > scenario as well? When we move processes we loop their pages tables
> > and move pages and their stats, is there a reason why we wouldn't be
> > able to do this with tmpfs mounts or bpf maps as well?
>
> Nothing is impossible but nothing is free as well. Moving charges around
> traditionally caused a lot of headaches in the past and never became
> reliable. There are inherent trade-offs here. You can make things more
> dynamic usually by making hot paths more expensive or doing some
> synchronization dancing which tends to be pretty hairy. People generally
> don't wanna make hot paths slower, so we tend to end up with something
> twisted which unfortunately turns out to be a headache in the long term.
>
> In general, I'd rather keep resource associations as static as possible.
> It's okay if we do something neat inside the kernel but if we create
> userspace expectation that resources can be moved around dynamically, we'll
> be stuck with that for a long time likely forfeiting future simplification /
> optimization opportunities.
>
> So, that's gonna be a fairly strong nack from my end.

Fair enough :)

Thanks for elaborating your point of view and the challenges that come
with this!

>
> Thanks.
>
> --
> tejun

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Mina Almasry]

On Tue, Jul 19, 2022 at 12:38 PM Tejun Heo <tj@kernel.org> wrote:
>
> On Tue, Jul 19, 2022 at 12:30:17PM -0700, Yosry Ahmed wrote:
> > Is there a reason why these resources cannot be moved across cgroups
> > dynamically? The only scenario I imagine is if you already have tmpfs
> > mounted and files charged to different cgroups, but once you attribute
> > tmpfs to one cgroup.charge_for.tmpfs (or sticky,..), I assume that we
> > can dynamically move the resources, right?
> >
> > In fact, is there a reason why we can't move the tmpfs charges in that
> > scenario as well? When we move processes we loop their pages tables
> > and move pages and their stats, is there a reason why we wouldn't be
> > able to do this with tmpfs mounts or bpf maps as well?
>
> Nothing is impossible but nothing is free as well. Moving charges around
> traditionally caused a lot of headaches in the past and never became
> reliable. There are inherent trade-offs here. You can make things more
> dynamic usually by making hot paths more expensive or doing some
> synchronization dancing which tends to be pretty hairy. People generally
> don't wanna make hot paths slower, so we tend to end up with something
> twisted which unfortunately turns out to be a headache in the long term.
>
> In general, I'd rather keep resource associations as static as possible.
> It's okay if we do something neat inside the kernel but if we create
> userspace expectation that resources can be moved around dynamically, we'll
> be stuck with that for a long time likely forfeiting future simplification /
> optimization opportunities.
>
> So, that's gonna be a fairly strong nack from my end.
>

Hmm, sorry I might be missing something but I don't think we have the
same thing in mind?

My understanding is that the sysadmin can do something like this which
is relatively inexpensive to implement in the kernel:


mount -t tmpfs /mnt/mymountpoint
echo "/mnt/mymountpoint" > /path/to/cgroup/cgroup.charge_for.tmpfs


At that point all tmpfs charges for this tmpfs are directed to
/path/to/cgroup/memory.current.

Then the sysadmin can do something like:


echo "/mnt/mymountpoint" > /path/to/cgroup2/cgroup.charge_for.tmpfs


At that point all _future_ charges of that tmpfs will go to
cgroup2/memory.current. All existing charges remain at
cgroup/memory.current and get uncharged from there. Per my
understanding there is no need to move all the _existing_ charges from
cgroup/memory.current to cgroup2/memory.current.

Sorry, I don't mean to be insistent, just wanted to make sure we have
the same thing in mind. Speaking for ourselves we have a very similar
implementation locally and is perfectly usable (and in fact addresses
a number of pain points related to shared memory charging) without
dynamically moving existing charges on reassignment (the second echo
in my example).

> Thanks.

>
> --
> tejun

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Tejun Heo]

Hello,

On Tue, Jul 19, 2022 at 12:47:39PM -0700, Mina Almasry wrote:
> Hmm, sorry I might be missing something but I don't think we have the
> same thing in mind?
> 
> My understanding is that the sysadmin can do something like this which
> is relatively inexpensive to implement in the kernel:
> 
> 
> mount -t tmpfs /mnt/mymountpoint
> echo "/mnt/mymountpoint" > /path/to/cgroup/cgroup.charge_for.tmpfs
> 
> 
> At that point all tmpfs charges for this tmpfs are directed to
> /path/to/cgroup/memory.current.
> 
> Then the sysadmin can do something like:
> 
> 
> echo "/mnt/mymountpoint" > /path/to/cgroup2/cgroup.charge_for.tmpfs
> 
> 
> At that point all _future_ charges of that tmpfs will go to
> cgroup2/memory.current. All existing charges remain at
> cgroup/memory.current and get uncharged from there. Per my
> understanding there is no need to move all the _existing_ charges from
> cgroup/memory.current to cgroup2/memory.current.

So, it's a lot better if the existing charges aren't moved around but it's
also kinda confusing if something can be moved around the tree arbitrarily
leaving charges behind. We already do get that from moving processes around
but most common usages are pretty static at this point and I think it'd be
better to avoid expanding the interface in that direction.

I'd much prefer something alont the line of `mount -t tmpfs -o cgroup=XXX`
where the tmpfs code checks whether the specified cgroup is one of the
ancestors and the mounting task has enough permission to shift the resource
there.

Thanks.

-- 
tejun

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Mina Almasry]

On Tue, Jul 19, 2022 at 12:54 PM Tejun Heo <tj@kernel.org> wrote:
>
> Hello,
>
> On Tue, Jul 19, 2022 at 12:47:39PM -0700, Mina Almasry wrote:
> > Hmm, sorry I might be missing something but I don't think we have the
> > same thing in mind?
> >
> > My understanding is that the sysadmin can do something like this which
> > is relatively inexpensive to implement in the kernel:
> >
> >
> > mount -t tmpfs /mnt/mymountpoint
> > echo "/mnt/mymountpoint" > /path/to/cgroup/cgroup.charge_for.tmpfs
> >
> >
> > At that point all tmpfs charges for this tmpfs are directed to
> > /path/to/cgroup/memory.current.
> >
> > Then the sysadmin can do something like:
> >
> >
> > echo "/mnt/mymountpoint" > /path/to/cgroup2/cgroup.charge_for.tmpfs
> >
> >
> > At that point all _future_ charges of that tmpfs will go to
> > cgroup2/memory.current. All existing charges remain at
> > cgroup/memory.current and get uncharged from there. Per my
> > understanding there is no need to move all the _existing_ charges from
> > cgroup/memory.current to cgroup2/memory.current.
>
> So, it's a lot better if the existing charges aren't moved around but it's
> also kinda confusing if something can be moved around the tree arbitrarily
> leaving charges behind. We already do get that from moving processes around
> but most common usages are pretty static at this point and I think it'd be
> better to avoid expanding the interface in that direction.
>

I think I'm flexible in this sense. Would you like the kernel to
prevent reattaching the tmpfs to a different cgroup? To be honest we
have a use case for that, but I'm not going to die on this hill. I
guess the worst case scenario is that I can carry a local patch on our
kernel which allows reattaching to a different cgroup and directs
future charges there...

> I'd much prefer something alont the line of `mount -t tmpfs -o cgroup=XXX`
> where the tmpfs code checks whether the specified cgroup is one of the
> ancestors and the mounting task has enough permission to shift the resource
> there.
>

Actually this is pretty much the same interface I opted for in my
original proposal (except I named it memcg= rather than cgroup=):
https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/

Curious, why do we need to check if the cgroup= is an ancestor? We
actually do have a use case where the cgroups are unrelated and the
common ancestor is root. Again, I'm not sure I want to die on this
hill. At worst I can remove the restriction in a local patch for our
kernel again...

Before I get too excited and implement these changes and submit
another iteration of my proposal above, I'd love to hear from
Johannes/Michal/Roman. My previous proposal was a pretty strong nack
from Johannes and Michal in particular.

> Thanks.
>
> --
> tejun

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Tejun Heo]

Hello,

On Tue, Jul 19, 2022 at 01:16:02PM -0700, Mina Almasry wrote:
> I think I'm flexible in this sense. Would you like the kernel to
> prevent reattaching the tmpfs to a different cgroup? To be honest we
> have a use case for that, but I'm not going to die on this hill. I
> guess the worst case scenario is that I can carry a local patch on our
> kernel which allows reattaching to a different cgroup and directs
> future charges there...

If it's not gonna be dynamic, putting it in a writable cgroupfs file feels
awakard to me, prone to creating incorrect expectations.

> > I'd much prefer something alont the line of `mount -t tmpfs -o cgroup=XXX`
> > where the tmpfs code checks whether the specified cgroup is one of the
> > ancestors and the mounting task has enough permission to shift the resource
> > there.
> 
> Actually this is pretty much the same interface I opted for in my
> original proposal (except I named it memcg= rather than cgroup=):
> https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/

Right. Hmm... the discussion w/ Johannes didn't seem to have concluded, so
continue that here, I guess?

If the consensus becomes that we want to allow charging resources to an
ancestor, I like the the mount option interface a lot more than other
proposals.

> Curious, why do we need to check if the cgroup= is an ancestor? We
> actually do have a use case where the cgroups are unrelated and the
> common ancestor is root. Again, I'm not sure I want to die on this
> hill. At worst I can remove the restriction in a local patch for our
> kernel again...

First of all, permission doesn't capture the whole picture due to delegation
boundaries. Maybe we can use the same perm check as delegation checks but
keeping it inside the subtree seems simpler and less confusing to me. We can
always relax if necessary in the future.

Thanks.

-- 
tejun

Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Michal Hocko]

On Tue 19-07-22 11:46:41, Mina Almasry wrote:
[...]
> An interface like cgroup.sticky.[bpf/tmpfs/..] would work for us
> similar to tmpfs memcg= mount option. I would maybe rename it to
> cgroup.charge_for.[bpf/tmpfs/etc] or something.
> 
> With regards to OOM, my proposal on this patchset is to return ENOSPC
> to the caller if we hit the limit of the remote memcg and there is
> nothing to kill:
> https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/

That would imply SIGBUS on the #PF path. Is this really the way how we
want to tell userspace that something they are not aware of like a limit
in a completely different resource domain has triggered?

> There is some precedent to doing this in the kernel. If a hugetlb
> allocation hits the hugetlb_cgroup limit, we return ENOSPC to the
> caller (and SIGBUS in the charge path). The reason there being that we
> don't support oom-kill or reclaim or swap for hugetlb pages.

Following hugetlb is not really a great idea because hugetlb has always
been quite special and its users are aware of that. The same doesn't
really apply to other resources like tmpfs.
 
> I think it is also reasonable to prevent removing the memcg if there
> is cgroup.charge_for.[bpf/tmpfs/etc] still alive. Currently we prevent
> removing the memcg if there are tasks attached. So we can also prevent
> removing the memcg if there are bpf/tmpfs charge sources pending.

I can imagine some way of keeping cgroups active even without tasks but
so far I haven't really seen a good way how to achieve that.

cgroup.sticky.[bpf/tmpfs/..] interface is really weird if you ask me.
For one thing I have hard time imagine how to identify those resources.
tmpfs by path is really strange because the same mount point can be
referenced through many paths. Not the mention the path can be
remounted/redirected to anything after the configurion which would just
lead to a lot of confusion.

Exposing internal ids is also far from great. It would also put an
additional burden on the kernel implementation to ensure there is no
overlap in resources among different cgroups.  Also how many of those
sticky resources do we want to grow?

To me this have way too many red flags that it sounds like an interface
which would break really easily.

The more I think about that the more I agree with Tejun that corner
cases are just waiting to jump out at us. 
-- 
Michal Hocko
SUSE Labs

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Alexei Starovoitov]

On Tue, Jul 12, 2022 at 09:40:13AM +0200, Michal Hocko wrote:
> On Mon 11-07-22 21:39:14, Alexei Starovoitov wrote:
> > On Mon, Jul 11, 2022 at 02:15:07PM +0200, Michal Hocko wrote:
> > > On Sun 10-07-22 07:32:13, Shakeel Butt wrote:
> > > > On Sat, Jul 09, 2022 at 10:26:23PM -0700, Alexei Starovoitov wrote:
> > > > > On Fri, Jul 8, 2022 at 2:55 PM Shakeel Butt <shakeelb@google.com> wrote:
> > > > [...]
> > > > > >
> > > > > > Most probably Michal's comment was on free objects sitting in the caches
> > > > > > (also pointed out by Yosry). Should we drain them on memory pressure /
> > > > > > OOM or should we ignore them as the amount of memory is not significant?
> > > > > 
> > > > > Are you suggesting to design a shrinker for 0.01% of the memory
> > > > > consumed by bpf?
> > > > 
> > > > No, just claim that the memory sitting on such caches is insignificant.
> > > 
> > > yes, that is not really clear from the patch description. Earlier you
> > > have said that the memory consumed might go into GBs. If that is a
> > > memory that is actively used and not really reclaimable then bad luck.
> > > There are other users like that in the kernel and this is not a new
> > > problem. I think it would really help to add a counter to describe both
> > > the overall memory claimed by the bpf allocator and actively used
> > > portion of it. If you use our standard vmstat infrastructure then we can
> > > easily show that information in the OOM report.
> > 
> > OOM report can potentially be extended with info about bpf consumed
> > memory, but it's not clear whether it will help OOM analysis.
> 
> If GBs of memory can be sitting there then it is surely an interesting
> information to have when seeing OOM. One of the big shortcomings of the
> OOM analysis is unaccounted memory.
> 
> > bpftool map show
> > prints all map data already.
> > Some devs use bpf to inspect bpf maps for finer details in run-time.
> > drgn scripts pull that data from crash dumps.
> > There is no need for new counters.
> > The idea of bpf specific counters/limits was rejected by memcg folks.
> 
> I would argue that integration into vmstat is useful not only for oom
> analysis but also for regular health check scripts watching /proc/vmstat
> content. I do not think most of those generic tools are BPF aware. So
> unless there is a good reason to not account this memory there then I
> would vote for adding them. They are cheap and easy to integrate.

We've seen enough performance issues with such counters.
So, no, they are not cheap.
Remember bpf has to be optimized for all cases.
Some of them process millions of packets per second.
Others do millions of map update/delete per second which means
millions of alloc/free.

> > > OK, thanks for the clarification. There is still one thing that is not
> > > really clear to me. Without a proper ownership bound to any process why
> > > is it desired/helpful to account the memory to a memcg?
> > 
> > The first step is to have a limit. memcg provides it.
> 
> I am sorry but this doesn't really explain it. Could you elaborate
> please? Is the limit supposed to protect against adversaries? Or is it
> just to prevent from accidental runaways? 

yes to above two.

> Is it purely for accounting
> purposes?

also soft yes. Once the user be able to select memcg it will become
a strong yes.

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Michal Hocko]

On Tue 12-07-22 11:40:18, Alexei Starovoitov wrote:
> On Tue, Jul 12, 2022 at 09:40:13AM +0200, Michal Hocko wrote:
> > On Mon 11-07-22 21:39:14, Alexei Starovoitov wrote:
> > > On Mon, Jul 11, 2022 at 02:15:07PM +0200, Michal Hocko wrote:
> > > > On Sun 10-07-22 07:32:13, Shakeel Butt wrote:
> > > > > On Sat, Jul 09, 2022 at 10:26:23PM -0700, Alexei Starovoitov wrote:
> > > > > > On Fri, Jul 8, 2022 at 2:55 PM Shakeel Butt <shakeelb@google.com> wrote:
> > > > > [...]
> > > > > > >
> > > > > > > Most probably Michal's comment was on free objects sitting in the caches
> > > > > > > (also pointed out by Yosry). Should we drain them on memory pressure /
> > > > > > > OOM or should we ignore them as the amount of memory is not significant?
> > > > > > 
> > > > > > Are you suggesting to design a shrinker for 0.01% of the memory
> > > > > > consumed by bpf?
> > > > > 
> > > > > No, just claim that the memory sitting on such caches is insignificant.
> > > > 
> > > > yes, that is not really clear from the patch description. Earlier you
> > > > have said that the memory consumed might go into GBs. If that is a
> > > > memory that is actively used and not really reclaimable then bad luck.
> > > > There are other users like that in the kernel and this is not a new
> > > > problem. I think it would really help to add a counter to describe both
> > > > the overall memory claimed by the bpf allocator and actively used
> > > > portion of it. If you use our standard vmstat infrastructure then we can
> > > > easily show that information in the OOM report.
> > > 
> > > OOM report can potentially be extended with info about bpf consumed
> > > memory, but it's not clear whether it will help OOM analysis.
> > 
> > If GBs of memory can be sitting there then it is surely an interesting
> > information to have when seeing OOM. One of the big shortcomings of the
> > OOM analysis is unaccounted memory.
> > 
> > > bpftool map show
> > > prints all map data already.
> > > Some devs use bpf to inspect bpf maps for finer details in run-time.
> > > drgn scripts pull that data from crash dumps.
> > > There is no need for new counters.
> > > The idea of bpf specific counters/limits was rejected by memcg folks.
> > 
> > I would argue that integration into vmstat is useful not only for oom
> > analysis but also for regular health check scripts watching /proc/vmstat
> > content. I do not think most of those generic tools are BPF aware. So
> > unless there is a good reason to not account this memory there then I
> > would vote for adding them. They are cheap and easy to integrate.
> 
> We've seen enough performance issues with such counters.

Not sure we are talking about the same thing. These counters are used by
the page allocator as well (e.g. PGALLOC, PGFREE) without a noticeable
overhead.

> So, no, they are not cheap.
> Remember bpf has to be optimized for all cases.
> Some of them process millions of packets per second.
> Others do millions of map update/delete per second which means
> millions of alloc/free.

I thought the whole point is to allocate from a different context than
the one where the memory is used.

In any case, these were my few cents to help with "usual pains when OOM
is hit". I can see you are not much into discussing in more details so
I won't burn much more of our time here.

Let me just reiterate that OOM reports with a large part of the
consumption outside of usual counters are a PITA and essentially
undebuggable without a local reproducer which can get pretty tricky with
custom eBPF programs running on the affected system you do not have
access to. So I believe that large in-kernel memory consumers should
be accounted somewhere so it is at least clear where one should look
for. If numbers tell that the accounting is prohibitely expensive than
it would be great to have an estimation at least.

Thanks

-- 
Michal Hocko
SUSE Labs

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Roman Gushchin]

On Tue, Jul 12, 2022 at 09:40:13AM +0200, Michal Hocko wrote:
> On Mon 11-07-22 21:39:14, Alexei Starovoitov wrote:
> > On Mon, Jul 11, 2022 at 02:15:07PM +0200, Michal Hocko wrote:
> > > On Sun 10-07-22 07:32:13, Shakeel Butt wrote:
> > > > On Sat, Jul 09, 2022 at 10:26:23PM -0700, Alexei Starovoitov wrote:
> > > > > On Fri, Jul 8, 2022 at 2:55 PM Shakeel Butt <shakeelb@google.com> wrote:
> > > > [...]
> > > > > >
> > > > > > Most probably Michal's comment was on free objects sitting in the caches
> > > > > > (also pointed out by Yosry). Should we drain them on memory pressure /
> > > > > > OOM or should we ignore them as the amount of memory is not significant?
> > > > > 
> > > > > Are you suggesting to design a shrinker for 0.01% of the memory
> > > > > consumed by bpf?
> > > > 
> > > > No, just claim that the memory sitting on such caches is insignificant.
> > > 
> > > yes, that is not really clear from the patch description. Earlier you
> > > have said that the memory consumed might go into GBs. If that is a
> > > memory that is actively used and not really reclaimable then bad luck.
> > > There are other users like that in the kernel and this is not a new
> > > problem. I think it would really help to add a counter to describe both
> > > the overall memory claimed by the bpf allocator and actively used
> > > portion of it. If you use our standard vmstat infrastructure then we can
> > > easily show that information in the OOM report.
> > 
> > OOM report can potentially be extended with info about bpf consumed
> > memory, but it's not clear whether it will help OOM analysis.
> 
> If GBs of memory can be sitting there then it is surely an interesting
> information to have when seeing OOM. One of the big shortcomings of the
> OOM analysis is unaccounted memory.
> 
> > bpftool map show
> > prints all map data already.
> > Some devs use bpf to inspect bpf maps for finer details in run-time.
> > drgn scripts pull that data from crash dumps.
> > There is no need for new counters.
> > The idea of bpf specific counters/limits was rejected by memcg folks.
> 
> I would argue that integration into vmstat is useful not only for oom
> analysis but also for regular health check scripts watching /proc/vmstat
> content. I do not think most of those generic tools are BPF aware. So
> unless there is a good reason to not account this memory there then I
> would vote for adding them. They are cheap and easy to integrate.
>  
> > > OK, thanks for the clarification. There is still one thing that is not
> > > really clear to me. Without a proper ownership bound to any process why
> > > is it desired/helpful to account the memory to a memcg?
> > 
> > The first step is to have a limit. memcg provides it.
> 
> I am sorry but this doesn't really explain it. Could you elaborate
> please? Is the limit supposed to protect against adversaries? Or is it
> just to prevent from accidental runaways? Is it purely for accounting
> purposes?
> 
> > > We have discussed something similar in a different email thread and I
> > > still didn't manage to find time to put all the parts together. But if
> > > the initiator (or however you call the process which loads the program)
> > > exits then this might be the last process in the specific cgroup and so
> > > it can be offlined and mostly invisible to an admin.
> > 
> > Roman already sent reparenting fix:
> > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/

Just to be clear:
for the actual memory which is backing up bpf maps (slabs, percpu or vmallocs)
reparenting was implemented several years ago. Nothing is changing here.

This patch only adds reparenting to the map->memcg pointer (by replacing it
to an objcg), which affects *new* allocations which are happening after
the deletion of the cgroup. This would help to reduce the number of dying cgroups,
but unlikely significantly, this is why it hasn't been implemented from scratch.

Thanks!

Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Michal Hocko]

On Fri 08-07-22 10:48:58, Alexei Starovoitov wrote:
> On Fri, Jul 08, 2022 at 03:41:47PM +0200, Michal Hocko wrote:
[...]
> > Finally it is not really clear to what kind of entity is the life time
> > of these caches bound to. Let's say the system goes OOM, is any process
> > responsible for it and a clean up would be done if it gets killed?
> 
> We've been asking these questions for years and have been trying to
> come up with a solution.
> bpf progs are not analogous to user space processes. 
> There are bpf progs that function completely without user space component.
> bpf progs are pretty close to be full featured kernel modules with
> the difference that bpf progs are safe, portable and users have
> full visibility into them (source code, line info, type info, etc)
> They are not binary blobs unlike kernel modules.
> But from OOM perspective they're pretty much like .ko-s.
> Which kernel module would you force unload when system is OOMing ?
> Force unloading ko-s will likely crash the system.
> Force unloading bpf progs maybe equally bad. The system won't crash,
> but it may be a sorrow state. The bpf could have been doing security
> enforcement or network firewall or providing key insights to critical
> user space components like systemd or health check daemon.
> We've been discussing ideas on how to rank and auto cleanup
> the system state when progs have to be unloaded. Some sort of
> destructor mechanism. Fingers crossed we will have it eventually.
> bpf infra keeps track of everything, of course.
> Technically we can detach, unpin and unload everything and all memory
> will be returned back to the system.
> Anyhow not a new problem. Orthogonal to this patch set.
> bpf progs have been doing memory allocation from day one. 8 years ago.
> This patch set is trying to make it 100% safe.
> Currently it's 99% safe.

OK, thanks for the clarification. There is still one thing that is not
really clear to me. Without a proper ownership bound to any process why
is it desired/helpful to account the memory to a memcg?

We have discussed something similar in a different email thread and I
still didn't manage to find time to put all the parts together. But if
the initiator (or however you call the process which loads the program)
exits then this might be the last process in the specific cgroup and so
it can be offlined and mostly invisible to an admin.

As you have explained there is nothing really actionable on this memory
by the OOM killer either. So does it actually buy us much to account?

-- 
Michal Hocko
SUSE Labs