From: Mark Jackson <mpfj-list@mimc.co.uk>
To: lkml <linux-kernel@vger.kernel.org>
Subject: Advice on mmap() "feature"
Date: Sun, 16 Sep 2012 20:21:12 +0100 [thread overview]
Message-ID: <505626A8.8040806@mimc.co.uk> (raw)
Apologies if this is the wrong place to post this query. Please feel
free to redirect me to the correct place.
I have come across a weird (but documented [1]) "feature" of mmap(),
which is:-
"The mmap()function adds an extra reference to the file associated with
the file descriptor fildeswhich is not removed by a subsequent close()
on that file descriptor. This reference is removed when there are no
more mappings to the file."
In my embedded application, this is resulting in the consumption of
available file descriptors.
As an example I wrote the following test running on Ubuntu 11.04 64bit.
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
#include <sys/mman.h>
#define FRAM_SIZE (64 * 1024)
#define FRAM_BASE_ADDRESS 0x00000000
int main(int argc, char **argv)
{
int i;
for (i = 0; i < 5000; i++)
{
// open the fram device
int m_fdFram = open("/dev/mem", O_RDWR | O_SYNC);
if (m_fdFram < 0)
{
printf("could not open /dev/mem, exiting with errno %d\n",
errno);
return 0;
}
// map the device to memory
char *m_pFram = (char *)mmap( 0,
FRAM_SIZE * sizeof(unsigned short),
PROT_READ | PROT_WRITE,
MAP_SHARED,
m_fdFram,
FRAM_BASE_ADDRESS);
if ((int)m_pFram == -1)
{
close(m_fdFram);
m_fdFram = -1;
printf("could not mmap, exiting with errno %d\n", errno);
return 0;
}
// now remove the mapping
if (m_pFram)
munmap(m_pFram, FRAM_SIZE);
if (m_fdFram != -1)
close(m_fdFram);
}
puts("sleeping");
sleep(50);
return 0;
}
$ gcc test.c -o test
$ cat /proc/sys/fs/file-nr
10016 0 387704
$ ./test &
sleeping
$ cat /proc/sys/fs/file-nr
15008 0 387704
As can be seen, when I run the test, it consumes 5000 fd's, but only
releases them when the application closes, 50 seconds later.
My application is designed to run for many years without a restart,
spawning other tasks to do various system jobs, these fd's never seem to
get released, and eventually the system runs out of available fd's.
So my questions are:-
(a) Since all the mappings have been removed, so why don't the fd's get
released ?
(b) Can I somehow force some form of garbage collection to allow the
fd's to be freed up ?
Again, apologies if this is the wrong place to ask, but I'm out of ideas.
Thanks in advance
Mark JACKSON
[1] http://pubs.opengroup.org/onlinepubs/007908775/xsh/mmap.html
next reply other threads:[~2012-09-16 20:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-16 19:21 Mark Jackson [this message]
2012-09-16 20:52 ` Advice on mmap() "feature" richard -rw- weinberger
2012-09-17 7:54 ` Mark Jackson
2012-09-17 11:17 ` Alan Cox
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=505626A8.8040806@mimc.co.uk \
--to=mpfj-list@mimc.co.uk \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox