AW: [bigmem-patch] 4GB with Linux on IA32

AW: [bigmem-patch] 4GB with Linux on IA32

[Wichert, Gerhard]

> > -----Ursprungliche Nachricht-----
> > Von: Matthew Wilcox [mailto:Matthew.Wilcox@genedata.com]
> > Gesendet am: Dienstag, 17. August 1999 16:32
> > An: Wichert, Gerhard
> > Cc: linux-kernel@vger.rutgers.edu; linux-mm@kvack.org
> > Betreff: Re: [bigmem-patch] 4GB with Linux on IA32
> > 
> > On Mon, Aug 16, 1999 at 06:29:30PM +0200, Andrea Arcangeli wrote:
> > > Performance degradation:
> > > 
> > > 	Close to zero.

So, here are some additional nubers based on this little worst case bench
from Andrea Arcangeli.

#define SIZE (700*1024*1024)

main()
{
	unsigned long start, stop;
	int i;
	char *buf = (char *)malloc(SIZE);

	if (!buf)
		perror("malloc");

	i = 0;

	__asm__ __volatile__ ("rdtsc" :"=a" (start)::"edx");
	for (; i < SIZE; i += 4096, buf += 4096)
		*(int *)buf = 0;

	__asm__ __volatile__ ("rdtsc" :"=a" (stop)::"edx");

	printf("ticks %ul\n", stop-start);
}

This bench shows the overhead for establishing the temporary kernel mapping
for the bigmem page.

Linux-2.3.13:
run 1
ticks 1313001994l
run 2
ticks 1310999320l
run 3
ticks 1309894069l
run 4
ticks 1313788902l
run 5
ticks 1308360521l

Linux-2.3.13 with bigmem support:
run 1
ticks 1331834802l
run 2
ticks 1332486766l
run 3
ticks 1332231641l
run 4
ticks 1332125591l
run 5
ticks 1333419476l

This shows that we get only approx. 2% overhead in the worst case. In
real-world applications you won't probably see any performance degradation.

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

Re: AW: [bigmem-patch] 4GB with Linux on IA32

[Rik van Riel]

On Wed, 18 Aug 1999, Wichert, Gerhard wrote:

> This shows that we get only approx. 2% overhead in the worst case. In
> real-world applications you won't probably see any performance
> degradation.

And even if it's possible to create even worse degradations,
it doesn't matter.

People can simply take into account the way the system works
and (if performance really matters) optimize for it. And if
performance doesn't matter, who cares?

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
--
work at:	http://www.reseau.nl/
home at:	http://www.nl.linux.org/~riel/

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

AW: [bigmem-patch] 4GB with Linux on IA32

[Wichert, Gerhard]

> -----Ursprungliche Nachricht-----
> Von: Thierry Vignaud [mailto:tvignaud@mandrakesoft.com]
> Gesendet am: Donnerstag, 19. August 1999 15:34
> An: Andrea Arcangeli
> Cc: Alan Cox; Kanoj Sarcar; torvalds@transmeta.com; sct@redhat.com;
> Gerhard.Wichert@pdb.siemens.de; Winfried.Gerhard@pdb.siemens.de;
> linux-kernel@vger.rutgers.edu; linux-mm@kvack.org
> Betreff: Re: [bigmem-patch] 4GB with Linux on IA32
> 
> Andrea Arcangeli wrote:
> > 
> > I uploaded a new bigmem-2.3.13-M patch here:
> > 
> >         
> ftp://e-mind.com/pub/andrea/kernel-patches/2.3.13/bigmem-2.3.13-M
> > 
> > (the raw-io must be avoided with bigmem enabled, since the 
> protection I
> > added in get_page_map() doesn't work right now)
> > 
> > If you'll avoid to do raw-io the patch should be safe and 
> ready to use.
> 
> since only recent motherboard support more than 512Mb RAM, and since
> they used i686 (PPro, P2, P3), why not use the pse36 
> extension of these
> cpu that enable to stock the segment length on 24bits, which give 64To
> when mem unit is 4b page.
> this'll make the limit much higher (say 128Mb RAM for the kernel space
> memory and 15,9To for the user space).

With pse36 only your physical address space will grow. Your virtual address
space is still limited to 4GB.

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

AW: [bigmem-patch] 4GB with Linux on IA32

[Wichert, Gerhard]

> -----Ursprungliche Nachricht-----
> Von: Matthew Wilcox [mailto:Matthew.Wilcox@genedata.com]
> Gesendet am: Dienstag, 17. August 1999 16:32
> An: Wichert, Gerhard
> Cc: linux-kernel@vger.rutgers.edu; linux-mm@kvack.org
> Betreff: Re: [bigmem-patch] 4GB with Linux on IA32
> 
> On Mon, Aug 16, 1999 at 06:29:30PM +0200, Andrea Arcangeli wrote:
> > Performance degradation:
> > 
> > 	Close to zero.
Here are some numbers I got when compiling the kernel on a 4-way 400MHz
Dechutes machine with 4GB memory.

Linux-2.3.13
time make -j 4 bzImage >/dev/null 2>&1

run 1
real	1m36.442s
user	4m49.060s
sys	0m22.300s

run 2
real	1m36.788s
user	4m48.920s
sys	0m22.290s

run 3
real	1m37.016s
user	4m48.670s
sys	0m22.910s

run 4
real	1m36.897s
user	4m48.800s
sys	0m22.390s

run 5
real	1m37.584s
user	4m48.680s
sys	0m22.180s



Linux-2.3.13 with bigmem support
time make -j 4 bzImage >/dev/null 2>&1

run 1
real	1m36.647s
user	4m50.340s
sys	0m21.870s

run 2
real	1m36.890s
user	4m49.780s
sys	0m22.410s

run 3
real	1m36.825s
user	4m49.360s
sys	0m22.930s

run 4
real	1m36.793s
user	4m50.180s
sys	0m22.270s

run 5
real	1m36.821s
user	4m50.500s
sys	0m22.030s

> 
> Have you got some lmbench results to back this up?
> 
What do you expect from lmbench. As far as I know it measures cache, memory
and tlb miss latencies. For this bench there is no difference if the mapping
goes to low or big memory.

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

AW: [bigmem-patch] 4GB with Linux on IA32

[Wichert, Gerhard]

> -----Ursprungliche Nachricht-----
> Von: Andrea Arcangeli [mailto:andrea@suse.de]
> Gesendet am: Dienstag, 17. August 1999 01:50
> An: Kanoj Sarcar
> Cc: alan@lxorguk.ukuu.org.uk; torvalds@transmeta.com; sct@redhat.com;
> Gerhard.Wichert@pdb.siemens.de; Winfried.Gerhard@pdb.siemens.de;
> linux-kernel@vger.rutgers.edu; linux-mm@kvack.org
> Betreff: Re: [bigmem-patch] 4GB with Linux on IA32
> 
> On Mon, 16 Aug 1999, Kanoj Sarcar wrote:
> 
> >I was also talking about drivers which assume that all of memory is
> >direct mapped. For example, __va and __pa assume this. There 
> might be 
> >other macros/procedures which have the same assumption built in. 
> >Basically, anything that is dependent on PAGE_OFFSET needs to be
> >checked. 
> 
> Only places that may deal with bigmem pages and the core of the kernel
> must be checked. I don't exclude there still something to fix 
> (as happened
> with kernel/ptrace.c and /proc/*/mem) but with the current design we
> shouldn't need to touch the device drivers at all.

The only bigmem pages a driver will see are pages from the user process
dedicated for I/O. The driver will use the macros to get the physical
address to build the scatter/gather list for DMA. In this case the macros
will work correctly because of the wrap around in the 32 bit address space.
For private buffers the driver will get space in the low memory, therefore
the macros will work as usual. 

> 
> The only real problem currently seems to be raw-io to me... (hints?)
> 
> Andrea
> 

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