# HIGHMEM Performance and Nvidia Conflicts?

## vbenares

Should I enable HIGHMEM?

I have read that if one has more than 896MB of RAM, one should enable HIGHMEM in the kernel.  BUT, I have also read that enabling HIGHMEM degrades performance and screws up the Nvidia drivers.  

I have 1G of RAM available and an Nvidia card.

```
mark@mantis mark $ dmesg

Linux version 2.4.20-gentoo-r6 (root@mantis) (gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)) #1 SMP Mon Aug 25 15:36:27 MST 2003

BIOS-provided physical RAM map:

 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)

 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)

 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)

 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)

 BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)

 BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)

 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)

Warning only 896MB will be used.

Use a HIGHMEM enabled kernel.

896MB LOWMEM available.

```

Thanks.

----------

## BradN

try it and find out  :Smile: 

I'm not sure, but maybe you can adjust the kernel/user memory size split to make it fit a gig of ram without it though?  1.5GB kernel/2.5GB user perhaps. It's in the kernel options somewhere I think.

----------

## swalker

HIGHMEM enabled.

```

bigblue root # cat /usr/src/linux/.config | grep HIGHMEM

# CONFIG_NOHIGHMEM is not set

CONFIG_HIGHMEM4G=y

# CONFIG_HIGHMEM64G is not set

CONFIG_HIGHMEM=y

```

1 Gig ram

```

bigblue root # free -m

             total       used       free     shared    buffers     cached

Mem:          1006        967         39          0        250        539

-/+ buffers/cache:        177        829

Swap:          980          2        978

```

nvidia drivers seem ok for me ...

```
bigblue root # glxgears

25593 frames in 5.0 seconds = 5118.600 FPS

26307 frames in 5.0 seconds = 5261.400 FPS

26287 frames in 5.0 seconds = 5257.400 FPS

```

What have you heard the problems were?  I've not noticed any problems yet. I did have to rebuild the nvidia drivers after I enabled himem.

fyi my nvidia versions.

```
*  media-video/nvidia-glx

      Latest version available: 1.0.4363

      Latest version installed: 1.0.4363

      Size of downloaded files: 4,099 kB

      Homepage:    http://www.nvidia.com/

      Description: XFree86 GLX libraries for the NVIDIA's X driver

 

*  media-video/nvidia-kernel

      Latest version available: 1.0.4363-r2

      Latest version installed: 1.0.4363-r2

      Size of downloaded files: 645 kB

      Homepage:    http://www.nvidia.com/

      Description: Linux kernel module for the NVIDIA's X driver

```

----------

## Forge

Just another note:

P4 2.8C, SMP kernel

1GB ram

GeForce FX 5900 Ultra

Working great. Played RTCW:ET a few minutes ago.

I can compile a no-HIGHMEM kernel and compare framerates, if you'd like, but I can tell you without even looking that it's not a big difference.

Works, anyways.

1.0-4496-r1 ebuilds.

----------

## McManus

Just a warning, nvidia and highmen on my smp dual Athlon-MP system gives me instability problems.  My computer just hangs left and right.  I had to go back to lowmem (or whatever you wanna call it -- NOT the highmem kernel) to get my system to be stable.

----------

## asph

i use my nvidia geforce4, 1gb ram, highmem, and no problems on ver 2.6.0-test4

I also did with older versions 2.4.x without problems  :Smile: 

----------

## vbenares

So far, so good.  BTW, should I enable HIGHMEM I/O as well as Highmem in the kernel?

----------

## nadamsieee

Enabling HIGHMEM can slow your box down.

 *HIGHMEM Overview wrote:*   

> 2.7 Performance
> 
> Of course there's a performance penality in accessing the memory after 1giga, this because we have to setup a virt-to-phys mapping and flush away old tlb entries before we can acces it. It's very rasonable to have such performance penality to handle much more memory.

 

The overview gets a bit cheery at this point, claiming that the performance hit is not noticable, and provides a simple benchmark to prove the point.  But as we all know, there are 3 kinds of lies:

 Lies

 Damn lies

 Benchmarks

 :Wink: 

----------

## Forge

typically;

speedup.from.more.ram > speed.hit.from.HIGHMEM

I've tested 512 and 1024, HIGHMEM on and off, and I haven't found anything that preferred my 1GB+LOWMEM config over the 1GB and HIGHMEM version.

Several things seemed to enjoy/make use of the extra ~150MB I pick up when I turn HIGHMEM on.

----------

## nadamsieee

 *Forge wrote:*   

> typically;
> 
> speedup.from.more.ram > speed.hit.from.HIGHMEM
> 
> I've tested 512 and 1024, HIGHMEM on and off, and I haven't found anything that preferred my 1GB+LOWMEM config over the 1GB and HIGHMEM version.
> ...

 

Can you provide some specifics? i.e. Can you point to some specific applications/tasks and how to measure the execution time for each? Typically, vague broad statements are fanboy fodder.  :Wink: 

But seriously, I would like to see some repeatable tests for HIGHMEM vs 'LOWMEM'.  In what situations does HIGHMEM speed up execution, and in what situations does it slow things down. Everyone assumes (or has been brainwashed into thinking) that more RAM = faster computing. RAM is much faster than a hard drive access, but its much slower than a cache access. Also, if you introduce extra overhead (in the form of extra opcode to do the HIGHMEM mapping) then those RAM accesses are by definition slower than a "normal' RAM access. So it really depends on the specifics of the application you're running.   :Smile: 

----------

## Forge

That's true, I was being excessively vague.

My very informal testing was based on a set of emerges that I'd run, along with a Quake 3 timedemo. The emerges were always faster overall with HIGHMEM, and the Quake 3 timedemo variance between HIGHMEM and LOWMEM runs was under the noise margin.

I chose Q3 timedemos as they are notorious for being exceedingly sensitive to memory bandwidth.

If you can think of any other, more formalized/standardized testing, I'd be happy to participate.

----------

## nadamsieee

 *Forge wrote:*   

> If you can think of any other, more formalized/standardized testing, I'd be happy to participate.

 

I'm not thinking of anything too complicated. For your emerge example we could write a simple bash script to calculate the time. (I don't have my bash programmer's ref in front of me, so this example script will probably have errors. I will debug it sometime tonight & edit the post)

```
#!/bin/bash

# print the current number of seconds since 1970-01-01 00:00:00 UTC

startTime=`date +%s`

echo ">>> start time: $startTime"

# now emerge something that uses alot of RAM when gcc compiles it

echo ">>> emerging package... this may take a while..."

emerge insertPackageNameHere

# print the current number of seconds since 1970-01-01 00:00:00 UTC

endTime=`date +%s`

echo ">>> end time: $endTime"
```

If we wanted to get really fancy we could have our bash script convert the time strings into integers and print out the difference. I would need my reference book for that though.   :Very Happy: 

Anyways, for a given test I want to be able to measure the actual time difference (repeatedly). Are the Q3 time demos scriptable?

----------

## pross

i use ac-sources with himem set a 4 gigs..

i have 1G of ram athlon-xp 3000+ and FX5900ultra

i use the ~x86 nvidia drivers and get no lockups at all and glxgears gives me 12000 fps  :Very Happy: 

----------

## meowsqueak

I have 1GB RAM (2 x 512) and I get segmentation faults from a lot of processes, with or without HIGHMEM enabled in my kernels. It's stable enough for X and mozilla to run fine all day, but then some bash script, or emacs, or init trying to halt will start throwing kernel OOPS's everywhere. The same machine running WinXP runs fine, no problems at all, and can even play games without crashing.

I'm using Linux 2.4.23 and the only patch is the xfs one.

----------

## lsiden

I use 2.4.20-Gentoo-r9 on a single Athlon-XP w/ the ASUS A7N8X ("nforce", "nvidia", n-whatever!).  I tried enabling HIMEM.  Big mistake!  The kernel went wild dumping stuff to the console.  I was so alarmed, I didn't bother to try to stop it with ctrl-s to see what it was saying.  I just rebooted from the previous kernel and undid the change.  So much for that experiment!

----------

## thoughtform

where is this in kernel config?

thanks,

Scorpaen

----------

## meowsqueak

I solved my crashing problem by lowering the RAM speed (I forget which parameter exactly) in the BIOS. Has been running stable for the last 6 months  :Smile: 

----------

## PrakashP

If you have just 1 GB of RAM, there is a smarter way of getting 1GB lowmem instead of using highmem. You have to patch the kernel though. Search at lkml for 2g/2g split. The patch I am talking about is infact a 1.2/2.8 split.

You basically have to change C00000 (or alike) to B00000 in two files.

```

dmesg|grep LOW

1023MB LOWMEM available.

```

----------

