From: Richard Palethorpe <rpalethorpe@suse.de>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] syscalls/mmap21: Add new test for mmap's ENOMEM case
Date: Fri, 08 Sep 2023 10:45:20 +0100 [thread overview]
Message-ID: <87v8clgfcb.fsf@suse.de> (raw)
In-Reply-To: <ZPCKzdDjSKzFayv_@yuki>
Hello,
Cyril Hrubis <chrubis@suse.cz> writes:
> Hi!
>> To be more precise in this test and checking for ENOMEM on exact mapping
>> when limit is crossed, I could only think of counting the existing
>> mappings from /proc/$pid/maps and counting the remaining possible
>> mappings. Is there any better approach if we want to test this for exact
>> case?
>
> If you want to check that we managed to create exactly the amount of
> mappings in this limit, this would be a sensible way to do that.
>
> However beware that this also depends on the overcommit settings. If
yes, and perhaps this can be effected by CGroups and resource limit
settings as well. I would assume there are lots of limits that could
effect the test.
> kernel is not set to overcommit and if the size of the memory needed to
> cross the maximal number of mappings would exceed available memory you
> would get ENOMEM before you manage to hit the limit. With overcommit
> enabled you can create mappings as long as the kernel has enough memory
> to hold the vma structures.
>
> At my system the limit is set to 65530 which on 4k page size would
> consume around 300MB, which does not seem to be much, but may still fail
> on small embedded boards with disabled overcommit. So either we try to
> set the limit to a lower value for the duration of the test, or allow
> the mmap() to fail sooner if we find that available memory is close to
> or smaller than number of mappings multiplied by page size.
That seems like the safest option without enumerating all of the
possible limits.
Setting to changes requested.
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2023-09-08 9:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-31 11:19 [LTP] [PATCH] syscalls/mmap21: Add new test for mmap's ENOMEM case Avinesh Kumar
2023-08-31 12:42 ` Cyril Hrubis
2023-09-08 9:45 ` Richard Palethorpe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v8clgfcb.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.