All of lore.kernel.org
 help / color / mirror / Atom feed
* Unused memory
@ 1999-01-10 16:22 Thomas Bogendoerfer
  1999-01-10 23:48 ` ralf
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas Bogendoerfer @ 1999-01-10 16:22 UTC (permalink / raw)
  To: linux-mips, linux; +Cc: ulfc

Hi,

maybe some of you might remember Ulf Carlsson's test program, which
allocates memory in a loop until it gets an error from malloc(). This
program failed on his Indy long before the machine was really out of 
memory.

I now know the reason for this. Before giving out memory via brk() the
kernel checks, whether there is enough memory. The kernel holds back
(2 + page_cache.min_percent + buffer_mem.min_pecent) percent of the
available memory (see function vm_enough_memory() in mm/mmap.c). Problem
on the Indy is, that num_physpages is wrong by 128MB, because we account
the memory by only looking at the highest page number and forget about 
holes in the memory map. And the Indy has a big hole between 0x80002000 
and 0x88002000 ...

Right now I can't think of a good fix for this problem. Any ideas ?

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]

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

* Re: Unused memory
  1999-01-10 16:22 Unused memory Thomas Bogendoerfer
@ 1999-01-10 23:48 ` ralf
  0 siblings, 0 replies; 2+ messages in thread
From: ralf @ 1999-01-10 23:48 UTC (permalink / raw)
  To: Thomas Bogendoerfer; +Cc: linux, linux-mips, linux-mips

On Sun, Jan 10, 1999 at 05:22:59PM +0100, Thomas Bogendoerfer wrote:

> I now know the reason for this. Before giving out memory via brk() the
> kernel checks, whether there is enough memory. The kernel holds back
> (2 + page_cache.min_percent + buffer_mem.min_pecent) percent of the
> available memory (see function vm_enough_memory() in mm/mmap.c). Problem
> on the Indy is, that num_physpages is wrong by 128MB, because we account
> the memory by only looking at the highest page number and forget about 
> holes in the memory map. And the Indy has a big hole between 0x80002000 
> and 0x88002000 ...
> 
> Right now I can't think of a good fix for this problem. Any ideas ?

Attached is a quickfix which just fixes the calculation of num_physpages.
The real thing is to us the PG_skip flag and implement the PageSkip macro.
See the Sparc / Sparc64 code for how to implement.  Implementing this
will save us alot of memory as well.  I'll post a real patch later.

  Ralf

--- arch/mips/mm/init.c.orig	Sun Jan 10 23:50:12 1999
+++ arch/mips/mm/init.c	Sun Jan 10 23:50:53 1999
@@ -247,8 +247,9 @@
 #endif
 
 	end_mem &= PAGE_MASK;
-	max_mapnr = num_physpages = MAP_NR(end_mem);
+	max_mapnr = MAP_NR(end_mem);
 	high_memory = (void *)end_mem;
+	num_physpages = 0;
 
 	/* mark usable pages in the mem_map[] */
 	start_mem = PAGE_ALIGN(start_mem);
@@ -278,6 +279,7 @@
 				datapages++;
 			continue;
 		}
+		num_physpages++;
 		atomic_set(&mem_map[MAP_NR(tmp)].count, 1);
 #ifdef CONFIG_BLK_DEV_INITRD
 		if (!initrd_start || (tmp < initrd_start || tmp >=

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

end of thread, other threads:[~1999-01-11  0:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1999-01-10 16:22 Unused memory Thomas Bogendoerfer
1999-01-10 23:48 ` ralf

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.