Anyone? Is this expected behaviour?

Nope looks like a bug to me.

Maybe this is something that is only supporeted in Cgroup V1

Here is the test for it.

	It("podman run memory-reservation test", func() {
		if podmanTest.Host.Distribution == "ubuntu" {
			Skip("Unable to perform test on Ubuntu distributions due to memory management")
		}

		cgroupsv2, err := cgroups.IsCgroup2UnifiedMode()
		Expect(err).To(BeNil())

		var session *PodmanSessionIntegration

		if cgroupsv2 {
			session = podmanTest.Podman([]string{"run", "--memory-reservation=40m", ALPINE, "sh", "-c", "cat /sys/fs/cgroup/$(sed -e 's|0::||' < /proc/self/cgroup)/memory.high"})
		} else {
			session = podmanTest.Podman([]string{"run", "--memory-reservation=40m", ALPINE, "cat", "/sys/fs/cgroup/memory/memory.soft_limit_in_bytes"})
		}

		session.WaitWithDefaultTimeout()
		Expect(session.ExitCode()).To(Equal(0))
		if cgroupsv2 {
			Expect(session.OutputToString()).To(Equal("max"))
		} else {
			Expect(session.OutputToString()).To(Equal("41943040"))
		}
	})


If this has no effect on V2, we should probably print a warning if the user sets it and document this behaviour in man page.

Giuseppe and Valentin, do you know for sure?

--memory-reservation under cgroup v2 is mapped to `memory.low`.

Can you check the value of that file?

(In reply to Giuseppe Scrivano from comment #4)
> --memory-reservation under cgroup v2 is mapped to `memory.low`.

Hmm, this changed from F31 cgroups v2 then. See "Additional Info" on comment 0. Is there some documentation about it somewhere? We are using those files in OpenJDK's container detection code and would like to have some references to refer to and why. Thanks!
 
> Can you check the value of that file?

Here you go. It's what you said:

$ podman run -ti --rm --memory-reservation=500m fedora:32 /bin/bash
[root@10037ca757b6 /]# cat /proc/self/cgroup
0::/
[root@10037ca757b6 /]# cat /sys/fs/cgroup/memory.high 
max
[root@10037ca757b6 /]# cat /sys/fs/cgroup/memory.low 
524288000

The question as to why this changed and whether it's going to be stable moving forward remains. Thanks, all!

The conversion from cgroup v1 to cgroup v2 happens in the OCI runtime.  For crun, the conversions are documented here: https://github.com/containers/crun/blob/master/crun.1.md#cgroup-v2

memory.high is not meant to be a reservation but a limit, so the previous conversion was wrong and it was fixed in crun 0.11.

(In reply to Giuseppe Scrivano from comment #6)
> The conversion from cgroup v1 to cgroup v2 happens in the OCI runtime.  For
> crun, the conversions are documented here:
> https://github.com/containers/crun/blob/master/crun.1.md#cgroup-v2
> 
> memory.high is not meant to be a reservation but a limit, so the previous
> conversion was wrong and it was fixed in crun 0.11.

OK, thanks!

Should 'memory.swap_max' be 'memory.swap.max' instead in that table? As per:
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory

"""
memory.swap.max

    A read-write single value file which exists on non-root cgroups. The default is “max”.

    Swap usage hard limit. If a cgroup’s swap usage reaches this limit, anonymous memory of the cgroup will not be swapped out.
"""

Closing as per comment 5 and comment 6. This got fixed in crun 0.11 to use memory.low instead. F31 had crun 0.8 which still contained the bug.

(In reply to Severin Gehwolf from comment #7)
> (In reply to Giuseppe Scrivano from comment #6)
> > The conversion from cgroup v1 to cgroup v2 happens in the OCI runtime.  For
> > crun, the conversions are documented here:
> > https://github.com/containers/crun/blob/master/crun.1.md#cgroup-v2
> > 
> > memory.high is not meant to be a reservation but a limit, so the previous
> > conversion was wrong and it was fixed in crun 0.11.
> 
> OK, thanks!
> 
> Should 'memory.swap_max' be 'memory.swap.max' instead in that table? As per:
> https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory
> 
> """
> memory.swap.max
> 
>     A read-write single value file which exists on non-root cgroups. The
> default is “max”.
> 
>     Swap usage hard limit. If a cgroup’s swap usage reaches this limit,
> anonymous memory of the cgroup will not be swapped out.
> """

yes thanks for noticing it.  I'll address it