linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Re: mmap() > phys mem problem
@ 2004-06-14 22:04 Ron Maeder
  2004-06-15  3:19 ` Nick Piggin
  0 siblings, 1 reply; 15+ messages in thread
From: Ron Maeder @ 2004-06-14 22:04 UTC (permalink / raw)
  To: nickpiggin; +Cc: riel, akpm, linux-mm

I tried upping /proc/sys/vm/min_free_kbytes to 4096 as suggested below, 
with the same results (grinding to a halt, out of mem).

Any other suggestions?  Thanks for your help.

Ron

---------- Forwarded message ----------
Date: Sun, 06 Jun 2004 11:55:39 +1000
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Ron Maeder <rlm@orionmulti.com>
Cc: Rik van Riel <riel@surriel.com>, linux-mm@kvack.org,
     Andrew Morton <akpm@osdl.org>
Subject: Re: mmap() > phys mem problem

Ron Maeder wrote:
> Thanks very much for your response.  I have had some help trying out the 
> patch and running recent versions of the kernel.  The problem is not 
> fixed in 2.6.6+patch or in 2.6.7-rc2.  Any other suggestions?
> 

OK, NFS is getting stuck in nfs_flush_one => mempool_alloc presumably
waiting for some network IO. Unfortunately at this point, the system
is so clogged up that order 0 GFP_ATOMIC allocations are failing in
this path: netedev_rx => refill_rx => alloc_skb. ie. deadlock.

Sadly this seems to happen pretty easily here. I don't know the
network layer, so I don't know what might be required to fix it or if
it is even possible.

This doesn't happen so easily with swap enabled (still theoretically
possible), because freeing block device backed memory should be
deadlock free, so you have another avenue to free memory. I assume
you want diskless clients, so this isn't an option.

You could try working around it by upping /proc/sys/vm/min_free_kbytes
maybe to 2048 or 4096.


--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

^ permalink raw reply	[flat|nested] 15+ messages in thread
* mmap() > phys mem problem
@ 2004-05-25 22:40 Ron Maeder
  2004-05-29  2:08 ` Rik van Riel
  0 siblings, 1 reply; 15+ messages in thread
From: Ron Maeder @ 2004-05-25 22:40 UTC (permalink / raw)
  To: linux-mm

I have a diskless x86 box running the 2.6.5rc3 kernel.  I ran a program
which mmap()'d a file that was larger than physical memory over NFS and
then began to write values to it.  The process grew until it was near the
size of phys mem, and then grinded to a halt and other programs, including 
daemons, were exiting when they should have stayed running.

If I run the program on a system that has some swap space, it completes 
without any issue.

It seems as if the OS will not write any dirty pages back to the mmap()'d 
file, and then eventually runs out of memory.

Is this an "undocumented feature" or is this a linux error?  I would
expect pages of the mmap()'d file would get paged back to the original
file. I know this won't be fast, but the performance is not an issue for
this application.

Below is an example that reproduces the problem on a machine without swap.  
If I do an occasional synchronous msync(MS_SYNC) (compiling -DNEVER), the
test case completes fine, while if I use an msync(MS_ASYNC) then other
programs exit as if I did no msync().

Many thanks,

Ron
---------------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/sysinfo.h>

#define MAX_UNSIGNED	((unsigned) (~0))
#define	FILE_MODE	(S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)

unsigned
total_ram()
{
    struct sysinfo	info;
    double		my_total_ram;

    if (sysinfo(&info) != 0) {
	perror("sysinfo");
	exit(1);
    }
    my_total_ram = ((double) info.totalram * (double) info.mem_unit);
    if (my_total_ram > (double) MAX_UNSIGNED) {
	fprintf(stderr, "'my_total_ram' too large for 'unsigned' type.");
	exit(1);
    }
    return((unsigned) my_total_ram);
}

int
main()
{
    unsigned	i;
    unsigned	addr_size;
    unsigned	mem_size;
    unsigned	*mem;
    char	swap_filename[20] = "thrash_swap";
    int		swap_filedes;

    mem_size = total_ram();
    mem_size -= (mem_size % sizeof(unsigned));	/* align to 'unsigned' size */
    /* compute the size of the address for 'unsigned' memory accesses */
    addr_size = ((mem_size / sizeof(unsigned)) - 1);

    (void) unlink(swap_filename);
    if ((swap_filedes = open(swap_filename, O_RDWR | O_CREAT | O_TRUNC,
			     FILE_MODE)) == -1) {
	perror("open: Can't open for writing");
	exit(1);
    }
    /* Set size of swap file */
    if (lseek(swap_filedes, (mem_size - 1), SEEK_SET) == (off_t) -1) {
	perror("lseek");
	exit(1);
    }
    if (write(swap_filedes, "", 1) != 1) {
	perror("write");
	exit(1);
    }
    if ((mem = (unsigned *) mmap(0, mem_size, PROT_READ | PROT_WRITE,
				 MAP_FILE | MAP_SHARED, swap_filedes, 0))
	== (unsigned *) -1) {
	perror("mmap");
	exit(1);
    }
    /* for this example just dirty each page. */
    for (i = 0; i < addr_size; i += 1024) {
	mem[i] = 0;
	if ((i & 0xfffff) == 0) {
#ifdef NEVER
	    if (msync(mem, mem_size, MS_SYNC) != 0) {
		perror("msync");
		exit(1);
	    }
#endif
	    printf(".");
	    fflush(stdout);
	}
    }
    if (munmap(mem, mem_size) != 0) {
	perror("munmap");
	exit(1);
    }
    if (close(swap_filedes) != 0) {
	perror("close");
	exit(1);
    }
    if (unlink(swap_filename) != 0) {
	perror("unlink");
	exit(1);
    }
    printf("\n");
    fflush(stdout);
    return(0);
}



--
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-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2004-06-16  6:37 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-14 22:04 mmap() > phys mem problem Ron Maeder
2004-06-15  3:19 ` Nick Piggin
2004-06-16  3:08   ` Nick Piggin
2004-06-16  6:37     ` Ron Maeder
  -- strict thread matches above, loose matches on Subject: below --
2004-05-25 22:40 Ron Maeder
2004-05-29  2:08 ` Rik van Riel
2004-05-30  4:47   ` Ron Maeder
2004-05-30  9:24     ` Nick Piggin
2004-05-30 10:15       ` Andrew Morton
2004-06-05 19:21       ` Ron Maeder
2004-06-06  1:55         ` Nick Piggin
2004-06-06 23:51           ` Rik van Riel
2004-06-07  3:59             ` Nick Piggin
2004-06-07 12:04               ` Rik van Riel
2004-06-08  0:03                 ` Nick Piggin

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