[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [LTP] mmap001 questions



Thanks for the clarification.  The test I'm porting can either map to
anonymous memory or to a file.  Basically, when I specify "anonymous
memory", it returns the error, but if I select "file" it runs.  This info
helps explain why the machine crashes when I select an amount of memory too
close to the available limit using the "anonymous memory" option.
Hopefully, I can get permission to release this test soon, so I can get
better input for debugging.....maybe I'll "modify" mmap001 to reflect the
test I'm working on and let everyone look at that.

Thanks,

- Robbie

Robert V. Williamson
Linux Technology Center
Phone: (512) 838-9295   T/L: 638-9295
Email: robbiew@us.ibm.com


Aaron Laffin <alaffin@sgi.com>@sgi.com on 03/09/2001 12:34:32 PM

Sent by:  alaffin@sgi.com


To:   Robert Williamson/Austin/IBM@IBMUS, ltp@oss.sgi.com
cc:
Subject:  Re: [LTP] mmap001 questions



Robert Williamson wrote:

> Using this
> test I'm able to push the memory to the limit of crashing the box, but if
I
> specify more memory than I actually have the appropriate "Cannot allocate
> memory" message occurs and the test is aborted.

What syscall does this error message come from?  Is it ENOMEM?  Then,
what type of mapping are you using?  mmap001 uses a shared mapping,
meaning changes to the pages are flushed to the file itself.  A private
mapping is very different in that changes are copy on write and those
changes are supported by normal paging mechanisms.  So, a private
mapping is at the mercy of the ram size and swap size.

To test this theory, I changed mmap001, replaceing MAP_SHARED with
MAP_PRIVATE.  Then I ran it on the same system in both modes.

Private version:

$ ./mmap001 -m 100000
mmap001     0  INFO  :  mmap()ing file of 100000 pages or 409600000
bytes
mmap001     1  FAIL  :  mmap() failed: 12: Cannot allocate memory

Shared version:

$ ./mmap001 -m 100000
mmap001     0  INFO  :  mmap()ing file of 100000 pages or 409600000
bytes
mmap001     1  PASS  :  mmap() completed successfully.
mmap001     0  INFO  :  touching mmaped memory
mmap001     2  PASS  :  we're still here, mmaped area must be good
mmap001     3  PASS  :  msync() was successful
mmap001     4  PASS  :  munmap() was successful

--aaron

--
Aaron Laffin
Silicon Graphics, Inc. OS Test Development
Email: alaffin@sgi.com Voice: 651-683-5756
USA/MN/EA/F6625/SSBU