From: Charles Shannon Hendrix <shannon@widomaker.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: nVidia driver uses far less memory now, was Re: Nvidia drivers and 2.6.x kernel
Date: Fri, 30 Jan 2004 22:41:36 -0500 [thread overview]
Message-ID: <20040131034136.GA17945@widomaker.com> (raw)
In-Reply-To: <20040127224946.GC23758@widomaker.com>
Tue, 27 Jan 2004 @ 17:49 -0500, Charles Shannon Hendrix said:
> nVidia has released drivers supporting kernel 2.6 on their website.
>
> They run nicely for me.
Followup note: Running the new nVidia drivers, I see a huge drop in the
size of the X server.
My normal X server virgual memory size was around 260MB. If I played a
game like Infiltration, it would rise to 300MB. After exiting the game,
the virtual size stayed where it was. It never shrunk, and it ate a lot
of swap space too.
Then I upgraded to the new nVidia drivers which support the 2.6 kernel,
and things have changed.
I noticed my system was swapping a lot less, but didn't have time to
look into it.
Today I did.
My X server now hovers around 76MB, virtual size. Loading Infiltration
causes it to grow to around 98MB. When I exit the game, it drops back
down to 76MB virtual.
It also seems to release memory after a program like The Gimp has been
running, though I've done less testing with that. I've observed a
110MB->78MB drop when exiting The Gimp, but didn't record the event.
Wow... I started out on 8-bit micros, and talking about "drops" of 32MB
amazes me sometimes.
Questions:
Is the new driver able to hide the graphics aperature, showing a more
true statistic on memory use?
Was the 2.6 kernel always capable of showing the right thing, and the
new driver being made for 2.6 is just working better?
Why does the virtual memory size shrink now? Could the new driver be
unmapping vitual memory to free it up?
I'm going to ask nVidia, but wanted to post here and also see if anyone
else noticed this.
--
shannon "AT" widomaker.com -- ["Star Wars Moral Number 17: Teddy bears are
dangerous in herds."]
next prev parent reply other threads:[~2004-01-31 4:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-21 23:04 Nvidia drivers and 2.6.x kernel Christian Unger
[not found] ` <400FB4AA.8000109@yahoo.com.br>
2004-01-22 11:52 ` Christian Unger
2004-01-22 12:12 ` Kieran
2004-01-22 22:42 ` Christian Unger
[not found] ` <401052C6.7040500@ihateaol.co.uk>
2004-01-25 23:24 ` Christian Unger
2004-01-27 22:49 ` Charles Shannon Hendrix
2004-01-31 3:41 ` Charles Shannon Hendrix [this message]
2004-01-22 23:48 ` Charles Shannon Hendrix
2004-01-23 1:59 ` pci_alloc_consistent() Leonid Grossman
2004-01-23 8:50 ` pci_alloc_consistent() Jes Sorensen
2004-01-23 14:37 ` pci_alloc_consistent() Leonid Grossman
2004-01-23 18:11 ` pci_alloc_consistent() Alex Williamson
2004-01-22 23:40 ` Nvidia drivers and 2.6.x kernel Charles Shannon Hendrix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040131034136.GA17945@widomaker.com \
--to=shannon@widomaker.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox