linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Locked memory questions
@ 2001-01-22 15:54 Mark_H_Johnson
  2001-01-30  9:20 ` Christoph Rohland
  0 siblings, 1 reply; 2+ messages in thread
From: Mark_H_Johnson @ 2001-01-22 15:54 UTC (permalink / raw)
  To: linux-mm; +Cc: Stanley_R_Allen-NR

I was surprised by a reference in the latest kernel traffic
(http://kt.linuxcare.com/kernel-traffic/latest.epl) to a VM problem with
large locked memory regions. I read linux-mm on a daily basis, but didn't
see this particular discussion go by. We're looking at deploying a large
real time system [hard deadlines, lots of locked memory] and have a few
questions based on that discussion...
 [1] Other than the kernel limit on the amount of locked memory [was 50% in
2.2.x], what should I be aware of when setting up a system with huge
amounts of locked memory [say, 75% locked on a 256 to 512 Mbyte machine]?
 [2] Does it matter that I have several threads that map that memory [from
10 to 50, varies by system]?
 [3] Does it matter that the target system is a Pentium III or not?
 [4] Are there any other "known problems" with Linux VM and locked memory?
If so, any idea on when they will be fixed? We're looking to go into system
testing this summer with delivery in November.
 [5] Are the algorithms you are considering for fixing page aging, etc. do
well with locked memory?
 [6] Where does it explain when a locked page is put into memory? I had
assumed it was done when the mlockall() call was done, but now I'm not so
sure. We could put a small hunk of code to walk the address space if
needed, but need to know for sure.
 [7] If I use mlockall(), does it lock the maximum stack size for the
thread its called from [or just the current stack extent]?
 [8] Please confirm - A process with its address space locked is NOT a
candidate for swapping.

In many ways, I'd like the kernel to ignore the locked memory regions from
its analysis for page aging, candidates for swapping, etc. We want to use
most of the CPU cycles to run our application, not manage the memory that
isn't going anywhere.

Thanks.

--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Locked memory questions
  2001-01-22 15:54 Locked memory questions Mark_H_Johnson
@ 2001-01-30  9:20 ` Christoph Rohland
  0 siblings, 0 replies; 2+ messages in thread
From: Christoph Rohland @ 2001-01-30  9:20 UTC (permalink / raw)
  To: Mark_H_Johnson; +Cc: linux-mm, Stanley_R_Allen-NR

Mark_H_Johnson@Raytheon.com writes:

> I was surprised by a reference in the latest kernel traffic
> (http://kt.linuxcare.com/kernel-traffic/latest.epl) to a VM problem with
> large locked memory regions. I read linux-mm on a daily basis, but didn't
> see this particular discussion go by. 

Was this the database lockup with locked SYSV shareed memory segments?
This was not discussed a lot but fixed easily. It was a bad
implementation in shmem.c

Greetings
                Christoph

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-01-30  9:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-01-22 15:54 Locked memory questions Mark_H_Johnson
2001-01-30  9:20 ` Christoph Rohland

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox