does the semantics of MAP_LOCKED is equal to mlock() function?

does the semantics of MAP_LOCKED is equal to mlock() function?

[long.wanglong]

Hi all:

In the latest kernel, i set the memory limit (4096) in a test cgroup. and add the test task.
the test code code is:

testcase 1: mmap with MAP_LOCKED flag(memsize = 8192)

185                 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
186                          MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, 0, 0);
187                 if (p == MAP_FAILED)
188                         err(1, "mmap(lock) failed");
					
expect: invoke OOM killer.
result: not invoke OOM killer.


testcase 2: mmap without MAP_LOCKED flag and the call mlock (memsize = 8192)

185                 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
186                          MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
187                 if (p == MAP_FAILED)
188                         err(1, "mmap(lock) failed");
189
190                 if (mlock(p, memsize) == -1)
191                         err(1, "mlock failed")

expect: invoke OOM killer.
result: invoke OOM killer.

in the Linux Programmer's Manual:

MAP_LOCKED (since Linux 2.5.37)
		Lock the pages of the mapped region into memory in the manner
		of mlock(2).  This flag is ignored in older kernels.
	
and
       mlock() locks pages in the address range starting at addr and
       continuing for len bytes.  All pages that contain a part of the
       specified address range are guaranteed to be resident in RAM when the
       call returns successfully; the pages are guaranteed to stay in RAM
       until later unlocked.
	
According to the description in the manual, the two testcases are equivalent.

why the first testcase does not invoke OOM killer?
does the mmap with MAP_LOCKED flag will not immediately allocate physical memory?


Best Regards
Wang Long

Re: does the semantics of MAP_LOCKED is equal to mlock() function?

[Michal Hocko]

See http://marc.info/?l=linux-mm&m=142122902313315&w=2 for more
information.

On Mon 19-01-15 14:17:43, long.wanglong wrote:
> Hi all:
> 
> In the latest kernel, i set the memory limit (4096) in a test cgroup. and add the test task.
> the test code code is:
> 
> testcase 1: mmap with MAP_LOCKED flag(memsize = 8192)
> 
> 185                 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
> 186                          MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, 0, 0);
> 187                 if (p == MAP_FAILED)
> 188                         err(1, "mmap(lock) failed");
> 					
> expect: invoke OOM killer.
> result: not invoke OOM killer.
> 
> 
> testcase 2: mmap without MAP_LOCKED flag and the call mlock (memsize = 8192)
> 
> 185                 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
> 186                          MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> 187                 if (p == MAP_FAILED)
> 188                         err(1, "mmap(lock) failed");
> 189
> 190                 if (mlock(p, memsize) == -1)
> 191                         err(1, "mlock failed")
> 
> expect: invoke OOM killer.
> result: invoke OOM killer.
> 
> in the Linux Programmer's Manual:
> 
> MAP_LOCKED (since Linux 2.5.37)
> 		Lock the pages of the mapped region into memory in the manner
> 		of mlock(2).  This flag is ignored in older kernels.
> 	
> and
>        mlock() locks pages in the address range starting at addr and
>        continuing for len bytes.  All pages that contain a part of the
>        specified address range are guaranteed to be resident in RAM when the
>        call returns successfully; the pages are guaranteed to stay in RAM
>        until later unlocked.
> 	
> According to the description in the manual, the two testcases are equivalent.
> 
> why the first testcase does not invoke OOM killer?
> does the mmap with MAP_LOCKED flag will not immediately allocate physical memory?
> 
> 
> Best Regards
> Wang Long
> 

-- 
Michal Hocko
SUSE Labs

Re: does the semantics of MAP_LOCKED is equal to mlock() function?

[Michal Hocko]

On Mon 19-01-15 10:46:56, Michal Hocko wrote:
[...]
> > testcase 2: mmap without MAP_LOCKED flag and the call mlock (memsize = 8192)
> > 
> > 185                 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
> > 186                          MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> > 187                 if (p == MAP_FAILED)
> > 188                         err(1, "mmap(lock) failed");
> > 189
> > 190                 if (mlock(p, memsize) == -1)
> > 191                         err(1, "mlock failed")
> > 
> > expect: invoke OOM killer.
> > result: invoke OOM killer.

Are you sure about this? memcg OOM killer shouldn't trigger even from
mlock path. It should just lead to ENOMEM. If you see the OOM killer
then it is probably coming from a page fault from a different source.
strace of your test would tell you more.
-- 
Michal Hocko
SUSE Labs

Re: does the semantics of MAP_LOCKED is equal to mlock() function?

[long.wanglong]

On 2015/1/19 19:01, Michal Hocko wrote:
> On Mon 19-01-15 10:46:56, Michal Hocko wrote:
> [...]
>>> testcase 2: mmap without MAP_LOCKED flag and the call mlock (memsize = 8192)
>>>
>>> 185                 p = mmap(NULL, memsize, PROT_WRITE | PROT_READ,
>>> 186                          MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
>>> 187                 if (p == MAP_FAILED)
>>> 188                         err(1, "mmap(lock) failed");
>>> 189
>>> 190                 if (mlock(p, memsize) == -1)
>>> 191                         err(1, "mlock failed")
>>>
>>> expect: invoke OOM killer.
>>> result: invoke OOM killer.
> 
> Are you sure about this? memcg OOM killer shouldn't trigger even from
> mlock path. It should just lead to ENOMEM. If you see the OOM killer
> then it is probably coming from a page fault from a different source.
> strace of your test would tell you more.
> 
hi, Michal Hocko

sorry for the wrong description in the email. i run the two testcase in kernel v3.10.63, not
the latest kernel.

in kernel v3.18, the two testcases can not invoke OOM killer.

The problem comes from the LTP tests, because the v3.10.61 lts apply the following patch:

f8a5117916dd2871c056963bf5ee0d1101c10099 mm: memcg: handle non-error OOM situations more gracefully
f79d6a468980516cbfb9e01313c846b82b9d2e7e mm: memcg: do not trap chargers with full callstack on OOM
7a147e0c45a8fa198ade4128bdcbf8592f48843e mm: memcg: rework and document OOM waiting and wakeup
11f34787b50ce71f66b85ad8790beaa5eee3f897 mm: memcg: enable memcg OOM killer only for user faults

as you said in: http://marc.info/?l=linux-api&m=142122902613316&w=2

"
The primary issue is that mmap doesn't report a failure if MAP_LOCKED fails to populate the area. Is
this the correct/expected behavior?
"

There is another problem:

in kernel v3.10.63  testcase 1 can not invoke OOM, but testcase2 can invoke OOM.
in kernel v3.18     both testcase 1 and testcase 2 can not invoke OOM.

in kernel v3.10.63, why testcase2  can invoke OOM killer?

Thanks


Best Regards
Wang Long

Re: does the semantics of MAP_LOCKED is equal to mlock() function?

[Michal Hocko]

On Tue 20-01-15 11:23:40, long.wanglong wrote:
[...]
> hi, Michal Hocko
> 
> sorry for the wrong description in the email. i run the two testcase in kernel v3.10.63, not
> the latest kernel.
> 
> in kernel v3.18, the two testcases can not invoke OOM killer.
> 
> The problem comes from the LTP tests, because the v3.10.61 lts apply the following patch:
> 
> f8a5117916dd2871c056963bf5ee0d1101c10099 mm: memcg: handle non-error OOM situations more gracefully
> f79d6a468980516cbfb9e01313c846b82b9d2e7e mm: memcg: do not trap chargers with full callstack on OOM
> 7a147e0c45a8fa198ade4128bdcbf8592f48843e mm: memcg: rework and document OOM waiting and wakeup
> 11f34787b50ce71f66b85ad8790beaa5eee3f897 mm: memcg: enable memcg OOM killer only for user faults
> 
> as you said in: http://marc.info/?l=linux-api&m=142122902613316&w=2
> 
> "
> The primary issue is that mmap doesn't report a failure if MAP_LOCKED fails to populate the area. Is
> this the correct/expected behavior?
> "
> 
> There is another problem:
> 
> in kernel v3.10.63  testcase 1 can not invoke OOM, but testcase2 can invoke OOM.

Both mlock and mmap(MAP_LOCKED) are using the same way to fault pages
backing mmaped area so they both are supposed to fail in the same way.
Meaning OOM before the above rework and ENOMEM with the change.
Maybe both of them are using a different exit paths when something is
faulted in and OOM happens for one while not for the other. strace would
tell you that.
-- 
Michal Hocko
SUSE Labs