Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 06-21-03, 05:08 PM   #1
lfc1001
Registered User
 
Join Date: Jun 2003
Posts: 4
Default Performance problems !

I'm running Redhat 9 on a Dell Inspiron 8200 laptop configured with:

2Ghz Intel P4
512 RAM
Geforce4 440 Go (64Mb)
1gb linux swap partition

Kernel version: 2.4.20-8
Nvidia driver - 1.0-4363
Video Bios# - 04.17.00.22.f6

My problem is that X runs like it's running in syrup. The X process is taking up about 290Mb of ram just sitting with an idle desktop, no other apps open except for the system monitor. If I open Mozilla, it takes about 45 seconds to launch, similarly for Evolution or anything from OpenOffice.

Surely there is something wrong as to why X should be grabbing as much as 290MBof memory. I've attached the relevant bits of the XF86Config file below and the latest X log.

I have an almost identically configured Inspiron 8000 running Redhat 9 (2.4.20.8) with an ATI Rage Mobility (32mb) card and it runs along just fine with X consuming a reasonable 67Mb of RAM). The 8000 machine has a slower proc but the same amount of RAM, so I'm reckoning the nvidia display drivers must have something to do with the performance problem.

Hopefully someone can help shed some light on this.

Thanks in advance

Gary

---- XF86Config ------
Section "Module"
Load "dbe"
Load "extmod"
Load "fbdevhw"
Load "glx"
Load "record"
Load "freetype"
Load "type1"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Dell 1600X Laptop Display Panel"
HorizSync 31.5 - 90.0
VertRefresh 59.0 - 85.0
ModeLine "1400x1050" 129.0 1400 1464 1656 1960 1050 1051 1054 1100 +hsync +vsync
ModeLine "1400x1050" 151.0 1400 1464 1656 1960 1050 1051 1054 1100 +hsync +vsync
ModeLine "1400x1050" 162.0 1400 1464 1656 1960 1050 1051 1054 1100 +hsync +vsync
ModeLine "1400x1050" 184.0 1400 1464 1656 1960 1050 1051 1054 1100 +hsync +vsync
Option "dpms"
EndSection

Section "Device"
Identifier "Videocard0"
Driver "nvidia"
VendorName "Videocard vendor"
BoardName "NVIDIA GeForce 4 (generic)"
VideoRam 65536
EndSection

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Modes "1600x1200"
EndSubSection
SubSection "Display"
Modes "1600x1200"
EndSubSection
SubSection "Display"
Depth 16
Modes "1600x1200" "1024x768"
EndSubSection
SubSection "Display"
Depth 24
Modes "1600x1200" "1024x768"
EndSubSection
EndSection

------------------------------
Attached Files
File Type: log xfree86.0.log (29.2 KB, 127 views)
lfc1001 is offline   Reply With Quote
Old 06-21-03, 07:24 PM   #2
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default Re: Performance problems !

Quote:
Originally posted by lfc1001
The X process is taking up about 290Mb of ram just sitting with an idle desktop, no other apps open except for the system monitor.
No, it isn't.

From the README:

Quote:
Q: Why does X use so much memory?

A: When measuring any application's memory usage, you must be
careful to distinguish between physical system RAM used and virtual
mappings of shared resources. For example, most shared libraries exist
only once in physical memory but are mapped into multiple processes.
This memory should only be counted once when computing total memory
usage. In the same way, the video memory on a graphics card or
register memory on any device can be mapped into multiple processes.
These mappings do not consume normal system RAM.

This has been a frequently discussed topic on XFree86 mailing
lists; see, for example:

http://marc.theaimsgroup.com/?l=xfre...5767116567&w=2

The `pmap` utility described in the above thread and available here:

http://web.hexapodia.org/~adi/pmap.c

is a useful tool in distinguishing between types of memory mappings.
For example, while `top` may indicate that X is using several hundred
MB of memory, the last line of output from pmap:

mapped: 287020 KB writable/private: 9932 KB shared: 264656 KB

reveals that X is really only using roughly 10MB of system RAM
(the "writable/private" value).

Note, also, that X must allocate resources on behalf of X clients (the
window manager, your web browser, etc); X's memory usage will increase
as more clients request resources such as pixmaps, and decrease as
you close X applications.
Grab that pmap.c file, do a make pmap in the directory you save it to, and then do ./pmap `pidof X`. I bet you'll see two 128MB mmap()s of /dev/nvidia0, and only about 15-30MB of real RAM used in the end.

As to why everything is running so slow, though... I'm not sure. What does hdparm -i /dev/hdX say? (replace X with the letter of the partition containing your partition; for example, if you installed to /dev/hdb5, the first logical partition on your primary slave drive, then use /dev/hdb in the hdparm command). What about plain old hdparm /dev/hdX?
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Old 06-23-03, 09:52 AM   #3
lfc1001
Registered User
 
Join Date: Jun 2003
Posts: 4
Default Performance problems !

Okay here's the output from pmap, you are correct.

---------------------
42134000 (131072 KB) rw-s (03:03 39638) /dev/nvidia0
4a134000 (131072 KB) rw-s (03:03 39638) /dev/nvidia0
52134000 (12292 KB) rw-p (00:00 0)
bfff8000 (32 KB) rwxp (00:00 0)
mapped: 310384 KB writable/private: 33736 KB shared: 268308 KB
---------------------

Now hdparm settings
----------------------

hdparm -i /dev/hda
Model=HITACHI_DK23EB-40, FwRev=00K0A0C0, SerialNo=1G2611
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78140160
IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 3: 2 3 4 5



hdparm /dev/hda

/dev/hda:
multcount = 16 (on)
IO_support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 4864/255/63, sectors = 78140160, start = 0
--------------------------

and
hdparm -tT /dev/hda

--------------------------
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.40 seconds =320.00 MB/sec
Timing buffered disk reads: 64 MB in 6.95 seconds = 9.21 MB/sec
# hdparm -tT /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.40 seconds =320.00 MB/sec
Timing buffered disk reads: 64 MB in 12.08 seconds = 5.30 MB/sec

------------------------

For some reason I'm now getting between 5 and 10Mb/s for disk reads when I used to get about 20mb/s. Now the performance of the machine is no different overall from when I was able to get 20mb/s, so I think these hdparm stats are a bit of a red herring.

Thanks for your help so far, hopefully this will help shed some light on it.
lfc1001 is offline   Reply With Quote
Old 06-23-03, 10:44 AM   #4
dpw2atox
Registered User
 
Join Date: May 2003
Posts: 170
Default

in /etc/rc.sysinit add the following line

hdparm -c1d1X69 /dev/hda

This should be located somewhere after the root filesystem is mounted.

This will set it to use ultra ata100.....if your drive can only run at uata66 then change the X69 to a X68.
dpw2atox is offline   Reply With Quote
Old 06-23-03, 04:56 PM   #5
lfc1001
Registered User
 
Join Date: Jun 2003
Posts: 4
Default

Okay I tried the modified hdparm and now it's reported as

---------------------
hdparm -tT /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.35 seconds =365.71 MB/sec
Timing buffered disk reads: 64 MB in 3.19 seconds = 20.06 MB/sec
[root@coronado root]# hdparm -tT /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.34 seconds =376.47 MB/sec
Timing buffered disk reads: 64 MB in 4.65 seconds = 13.76 MB/sec
[root@coronado root]# hdparm -tT /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.49 seconds =261.22 MB/sec
Timing buffered disk reads: 64 MB in 3.60 seconds = 17.78 MB/sec

--------------------------------

However there is no noticeable performance change. I don't know why X would report to be using 290Mb on one RH9 machine and report 65Mb on another identical machine with the same X version and the only difference being the video driver. This may not have anything to do with it but it just doesn't make much sense to me.
lfc1001 is offline   Reply With Quote
Old 06-23-03, 07:25 PM   #6
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default

Quote:
Originally posted by lfc1001
I don't know why X would report to be using 290Mb on one RH9 machine and report 65Mb on another identical machine with the same X version and the only difference being the video driver.
Because the "nv" driver does not use /dev/nvidia0; it does not have that double-mmap() in there.

The actual RAM in use is almost exactly the same, I'd bet. Don't bother chasing that; it's assuredly a red herring.

Quote:
This may not have anything to do with it but it just doesn't make much sense to me.
It's because top (or ps, or whatever you're using) is reporting ALL of the virtual memory in use by the process (it's giving you the number that pmap called "mapped"). This includes two maps of size 128MB, that isn't really coming from physical RAM -- it's coming from your video memory (it seems to map in 128MB regardless of how much video memory you have; I'd guess it just maps in the maximum available on any video card, then limits the accesses, or something, but of course, I can't see the source any more than you can, so this might not be it).

But, memory usage aside, something is being slow when you start up very large programs (that's what all of what you've talked about, Mozilla, Evolution, and OpenOffice, have in common; they're EXTREMELY huge). Maybe you could run strace on one of them, and redirect stderr to a log file? Then have another process write timestamps to that log every five or ten seconds. See if you can figure out what on earth is taking so long...
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Old 06-25-03, 12:58 AM   #7
lfc1001
Registered User
 
Join Date: Jun 2003
Posts: 4
Default

This entry in the logfile wouldn't have anything to do with it would it ?

Maximum main memory to use for agp memory: 439M

Is this a default based on the system ram and again it won't actually use this amount of memory ?


-----------------------------------------
Jun 23 14:32:22 coronado kernel: 0: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4363 Sat Apr 19 17:46:46 PDT 2003
Jun 23 14:32:22 coronado insmod: Warning: loading /lib/modules/2.4.20-8/kernel/drivers/video/nvidia.o will taint the kernel: non-GPL license - NVIDIA
Jun 23 14:32:22 coronado insmod: See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Jun 23 14:32:22 coronado insmod: Module nvidia loaded, with warnings
Jun 23 14:32:23 coronado kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann
Jun 23 14:32:23 coronado kernel: agpgart: Maximum main memory to use for agp memory: 439M
Jun 23 14:32:23 coronado kernel: agpgart: Detected Intel i845 chipset
Jun 23 14:32:23 coronado kernel: agpgart: AGP aperture is 64M @ 0xe8000000
--------------------------------------------
lfc1001 is offline   Reply With Quote
Old 06-25-03, 01:44 PM   #8
hohlraum
Registered User
 
Join Date: Mar 2003
Posts: 12
Default

Dell laptops are just slow under linux I dunno what the deal is. We have several here at work (P4's) and I installed RH9 on one. Its a dog. OO.org takes FOREVER to start up. My guess it is some other chipset or harddrive related issue with redhat's kernel or 2.4 in general. These machines are kinda doggy under windows as well. My guess is crappy slow harddrives.
hohlraum is offline   Reply With Quote

Old 06-25-03, 06:53 PM   #9
Ender
Registered User
 
Join Date: Apr 2003
Location: Maryland
Posts: 10
Default

Try using the 3123 drivers. Some 2d functions are slower than **** with the 4xxx drivers. This is easily verifiable, if you interested*.

Your apps starting slow may just be your imagination, after noticing how friggin slow some things are drawing... That's been my experience with the 4xxx drivers. Although, now that I think about it, it wasn't just drawing that seemed slow while using those lousy drivers... probably just my memory screwing with me though.

* use galeon 1.3.x. close all tabs(so that the tab bar is closed), and open the menus and drag the mouse around in the menus. open two or more tabs, and do the same, and watch the menus crawl. use ANY other video driver, and this does not happen.
__________________
Using Linux for 6+ years...
Ender is offline   Reply With Quote
Old 06-25-03, 08:37 PM   #10
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default

Quote:
Originally posted by Ender
* use galeon 1.3.x. close all tabs(so that the tab bar is closed), and open the menus and drag the mouse around in the menus. open two or more tabs, and do the same, and watch the menus crawl. use ANY other video driver, and this does not happen.
Works just wonderfully for me. No menus "crawling" at all. Of course, this is Mozilla 1.3.X (actually, CVS from Apr. 2), not Galeon 1.3.X, but it's the same codebase... right? I'm using the 4363 drivers, with RenderAccel turned on (it's stable for me at least; that isn't the case for everyone, though, which is why it's off by default).

Quote:
Originally posted by lfc1001
This entry in the logfile wouldn't have anything to do with it would it ?

Maximum main memory to use for agp memory: 439M

Is this a default based on the system ram and again it won't actually use this amount of memory ?
The way I understand it, that's pretty much the case, yes. That's why it's the "maximum" amount of RAM to use for AGP, and not the "current" amount of RAM to use for AGP.

Quote:
Jun 23 14:32:23 coronado kernel: agpgart: AGP aperture is 64M @ 0xe8000000
Your motherboard chipset won't let the system use more than 64MB of RAM for AGP. That's what the aperture is -- the maximum amount permissible. I'm not sure where the other 439M value is coming from, though (probably, as you suspect, the total system RAM).
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Old 06-26-03, 03:10 PM   #11
Ender
Registered User
 
Join Date: Apr 2003
Location: Maryland
Posts: 10
Default

Quote:
Originally posted by bwkaz
Works just wonderfully for me. No menus "crawling" at all. Of course, this is Mozilla 1.3.X (actually, CVS from Apr. 2), not Galeon 1.3.X, but it's the same codebase... right?
No, not right, not right at all. Galeon just uses the Mozilla rendering engine, ie. is has it's own interface, which uses native GTK2 widgets. Galeon is a GNOME 2 app.
__________________
Using Linux for 6+ years...
Ender is offline   Reply With Quote
Old 06-26-03, 05:44 PM   #12
bwkaz
Registered User
 
Join Date: Sep 2002
Posts: 2,262
Default

So the bug is with Gtk2 menus? Shouldn't The Gimp, version 1.3.11, configured with Gtk2 support (if that wasn't the default for Gimp development versions when I built this), do the same thing? Because it's not...
__________________
Registered Linux User #219692
bwkaz is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
Unity 5.12 Fixes Ubuntu OpenGL Performance Problems News Archived News Items 0 06-11-12 01:20 PM
Boost Your Performance Goals 10x ' This Week on inside* Publications News Archived News Items 0 05-13-12 05:20 PM
NVIDIA Unleashes the GeForce GTX 670 Graphics Card ' Performance Perfected (WCCFTECH) News GeForce GTX 670 Reviews 0 05-10-12 08:40 AM
Rumor regarding lack of 680 availability ViN86 Rumor Mill 6 05-09-12 04:48 PM
My UT2003 Tweak Guide DXnfiniteFX Gaming Central 48 10-30-02 11:59 PM

All times are GMT -5. The time now is 05:38 AM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.