From: Hubertus Franke <firstname.lastname@example.org> To: Andrew Morton <email@example.com>, Mark_H_Johnson@raytheon.com Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH] recognize MAP_LOCKED in mmap() call Date: Wed, 25 Sep 2002 11:42:29 -0400 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <3D88D9DE.2FB9A23D@digeo.com> On Wednesday 18 September 2002 03:54 pm, Andrew Morton wrote: > Mark_H_Johnson@raytheon.com wrote: > > Andrew Morton wrote: > > >(SuS really only anticipates that mmap needs to look at prior mlocks > > >in force against the address range. It also says > > > > > > Process memory locking does apply to shared memory regions, > > > > > >and we don't do that either. I think we should; can't see why SuS > > >requires this.) > > > > Let me make sure I read what you said correctly. Does this mean that > > Linux 2.4 (or 2.5) kernels do not lock shared memory regions if a process > > uses mlockall? > > Linux does lock these regions. SuS seems to imply that we shouldn't. > But we should. > > > If not, that is *really bad* for our real time applications. We don't > > want to take a page fault while running some 80hz task, just because some > > non-real time application tried to use what little physical memory we > > allow for the kernel and all other applications. > > > > I asked a related question about a week ago on linux-mm and didn't get a > > response. Basically, I was concerned that top did not show RSS == Size > > when mlockall(MCL_CURRENT|MCL_FUTURE) was called. Could this explain the > > difference or is there something else that I'm missing here? > > That mlockall should have faulted everything in. It could be an > accounting bug, or it could be a bug. That's not an aspect which > gets tested a lot. I'll take a look. This is what the manpage says... mlockall disables paging for all pages mapped into the address space of the calling process. This includes the pages of the code, data and stack segment, as well as shared libraries, user space kernel data, shared memory and memory mapped files. All mapped pages are guaranteed to be resident in RAM when the mlockall system call returns successfully and they are guaranteed to stay in RAM until the pages are unlocked again by munlock or munlockall or until the process terminates or starts another program with exec. Child processes do not inherit page locks across a fork. Do you read that all pages must be faulted in apriori ? Or is it sufficient to to make sure non of the currently mapped pages are swapped out and future swapout is prohibited. This still allows for page faults on pages that have not been mapped in the specified range or process. If required the app could touch these and they wouldn't be swapped later. -- -- Hubertus Franke (firstname.lastname@example.org)
next prev parent reply other threads:[~2002-09-25 15:41 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-09-18 19:18 Mark_H_Johnson 2002-09-18 19:39 ` Rik van Riel 2002-09-18 19:54 ` Andrew Morton 2002-09-25 15:42 ` Hubertus Franke [this message] 2002-09-25 16:35 ` Andrew Morton 2002-09-25 15:36 ` Hubertus Franke -- strict thread matches above, loose matches on Subject: below -- 2002-09-25 16:57 Mark_H_Johnson 2002-09-13 3:33 [PATCH] per-zone kswapd process Dave Hansen 2002-09-13 13:05 ` Alan Cox 2002-09-13 21:30 ` William Lee Irwin III 2002-09-18 16:07 ` [PATCH] recognize MAP_LOCKED in mmap() call Hubertus Franke 2002-09-18 16:29 ` Andrew Morton
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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=Mark_H_Johnson@raytheon.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] recognize MAP_LOCKED in mmap() call' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).