linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Re: Query on memory management
@ 2000-04-07 19:41 Mark_H_Johnson
  0 siblings, 0 replies; 4+ messages in thread
From: Mark_H_Johnson @ 2000-04-07 19:41 UTC (permalink / raw)
  To: linux-mm; +Cc: ak

A short follow up to this response - I looked at the per process limits
[see Andi's answer to my (2) below] but it appears that they are not all
implemented. If you use bash to set the "max memory size" limit (which maps
into RLIMIT_RSS, defined in resource.h) - you can see that the value is
set, but apparently no code in Linux 2.2.14 uses this value. I grep'd the
source code & I could find it defined, but never used [except to set &
display].

To demonstrate, I can provide a sample program that maps a file into your
memory space & traverses it. You can set a small memory limit, run the
program, and see RSS grow well past the set limit (I set the limit to 8192
kbytes, file size was 30M, and saw >20M for RSS). If the file size is too
big, the code in /arch/i386/mm/fault.c will kill this process (as well as
others) if you run out of physical memory - even though you have plenty of
swap space left. You can disable that "kill code" in fault.c [what I
referred to in (3) below] and the program will run successfully to
completion in all cases, but the system is very sluggish. In addition, if
the mapped file is on an nfs volume, nfs will generate a lot of error
messages on the console.

Can someone comment on when the memory resource limits will be implemented
[or if help is needed to do so]?

If already implemented on the developmental kernel, where should I look for
patches for this specific change?

Thanks.
--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>
----- Forwarded by Mark H Johnson/RTS/Raytheon/US on 04/07/00 02:14 PM
-----
                                                                                                                    
                    Andi Kleen                                                                                      
                    <ak@muc.de>          To:     Mark H Johnson/RTS/Raytheon/US@RTS                                 
                                         cc:     linux-mm@kvack.org                                                 
                    04/06/00             Subject:     Re: Query on memory management                                
                    10:30 AM                                                                                        
                                                                                                                    
                                                                                                                    



On Thu, Apr 06, 2000 at 04:18:24PM +0200, Mark_H_Johnson@Raytheon.com
wrote:
[snip]
>
> (2) I've seen traffic related to "out of memory" problems. How close are
we
> to a permanent solution & do you need suggestions? For example, I can't
> seem to find any per-process limits to the "working set or virtual size"
> (could refer to either the number of physical or virtual pages a process
> can use). If that was implemented, some of the problems you have seen
with
> rogue processes could be prevented.

There are per process limits, settable using ulimit
When you set suitable process limits and limit the number of processes you
should never run out of swap.

>
> (3) Re: out of memory. I also saw code in 2.2.14 [arch/i386/mm/fault.c]

> prevents the init task (pid==1) from getting killed. Why can't that
> solution be applied to all tasks & let kswapd (or something else) keep
> moving pages to the swap file (or memory mapped files) & kill tasks if
and
> only if the backing store on disk is gone?

[snip]

-Andi



--
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] 4+ messages in thread

* Re: Query on memory management
  2000-04-06 15:30 ` Andi Kleen
@ 2000-04-06 18:30   ` Jamie Lokier
  0 siblings, 0 replies; 4+ messages in thread
From: Jamie Lokier @ 2000-04-06 18:30 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Mark_H_Johnson, linux-mm

Andi Kleen wrote:
> > (4) Is there a "hook" for user defined page replacement or page fault
> > handling? I could not find one.
> 
> Just mprotect() the data in user space and set a signal handler for SIGSEGV
> The fault address can be read from the sigcontext_struct passed to the
> signal handler.

But note that this does not handle page faults when systems calls access
the memory.  I.e. you'll get EFAULTs when you read/write/ioctl the
protected memory region instead of triggering your SEGV handler.

enjoy,
-- Jamie
--
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] 4+ messages in thread

* Re: Query on memory management
  2000-04-06 14:16 Mark_H_Johnson
@ 2000-04-06 15:30 ` Andi Kleen
  2000-04-06 18:30   ` Jamie Lokier
  0 siblings, 1 reply; 4+ messages in thread
From: Andi Kleen @ 2000-04-06 15:30 UTC (permalink / raw)
  To: Mark_H_Johnson; +Cc: linux-mm

On Thu, Apr 06, 2000 at 04:18:24PM +0200, Mark_H_Johnson@Raytheon.com wrote:
> Questions -
> (1) What hard limits are there on how much memory can be mlock'd? I see
> checks [in mm/mlock.c] related to num_physpages/2, but can't tell if that
> is a system wide limit or a limit per process.

system wide
You can probably change it if you know what you're doing. 

> 
> (2) I've seen traffic related to "out of memory" problems. How close are we
> to a permanent solution & do you need suggestions? For example, I can't
> seem to find any per-process limits to the "working set or virtual size"
> (could refer to either the number of physical or virtual pages a process
> can use). If that was implemented, some of the problems you have seen with
> rogue processes could be prevented.

There are per process limits, settable using ulimit
When you set suitable process limits and limit the number of processes you
should never run out of swap. 

> 
> (3) Re: out of memory. I also saw code in 2.2.14 [arch/i386/mm/fault.c]

> prevents the init task (pid==1) from getting killed. Why can't that
> solution be applied to all tasks & let kswapd (or something else) keep
> moving pages to the swap file (or memory mapped files) & kill tasks if and
> only if the backing store on disk is gone?

Tasks are supposed to be only killed when you ran out of swap, or it ran out of
free pages that it cannot swap anymore. Some services like networking
may run out of memory earlier becaue they cannot swap and rely on a free
GFP_ATOMIC pool of pages.
> 
> (4) Is there a "hook" for user defined page replacement or page fault
> handling? I could not find one.

Just mprotect() the data in user space and set a signal handler for SIGSEGV
The fault address can be read from the sigcontext_struct passed to the
signal handler.



-Andi
--
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] 4+ messages in thread

* Query on memory management
@ 2000-04-06 14:16 Mark_H_Johnson
  2000-04-06 15:30 ` Andi Kleen
  0 siblings, 1 reply; 4+ messages in thread
From: Mark_H_Johnson @ 2000-04-06 14:16 UTC (permalink / raw)
  To: linux-mm

We are looking to port some real-time applications from a larger Unix
system to a cluster of PC's running Linux. I've read through the kernel
code a few times, on both 2.2.10 and 2.2.14, but I find it hard to
understand w/o some more information.

Some of the memory related capabilities we need include:
 - memory locking [on the order of 60-80% of real memory] on the target
system.
 - build and test large subsets on a development machine in non real time.
Perhaps run with "single cycle" or 1/10th real time performance. Swapping
is OK if it means that I don't have to wait until 3am to get time on a
target system. I'm worried about reported "out of memory" problems.
 - control of page fault handling; we currently emulate flight hardware by
trapping memory accesses to I/O devices. I see a similar issue with paging
large working sets of data from static files (e.g., for a visual system)
where smart use of page replacement algorithms can simplify implementation
of lookahead.

Questions -
(1) What hard limits are there on how much memory can be mlock'd? I see
checks [in mm/mlock.c] related to num_physpages/2, but can't tell if that
is a system wide limit or a limit per process.

(2) I've seen traffic related to "out of memory" problems. How close are we
to a permanent solution & do you need suggestions? For example, I can't
seem to find any per-process limits to the "working set or virtual size"
(could refer to either the number of physical or virtual pages a process
can use). If that was implemented, some of the problems you have seen with
rogue processes could be prevented.

(3) Re: out of memory. I also saw code in 2.2.14 [arch/i386/mm/fault.c]
prevents the init task (pid==1) from getting killed. Why can't that
solution be applied to all tasks & let kswapd (or something else) keep
moving pages to the swap file (or memory mapped files) & kill tasks if and
only if the backing store on disk is gone?

(4) Is there a "hook" for user defined page replacement or page fault
handling? I could not find one.

(5) If the answer to (4) is no, could I generate a loadable module that
handled the page fault trap, and then checked a status in the task block to
determine if I should just call the default page fault handler or handle
the fault myself?

Any feedback on these questions is appreciated. 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] 4+ messages in thread

end of thread, other threads:[~2000-04-07 19:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-07 19:41 Query on memory management Mark_H_Johnson
  -- strict thread matches above, loose matches on Subject: below --
2000-04-06 14:16 Mark_H_Johnson
2000-04-06 15:30 ` Andi Kleen
2000-04-06 18:30   ` Jamie Lokier

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