No, I mean the Nvidia proprietary drivers from their site, currently
185.18.14, 64-bit. The card is a 7950GTX, 512mb I think.
I haven't used the default NV drivers in ages, as I tend to rely on the
acceleration too much. I haven't tried Nouveau, though from what I read
it's something of a basketcase still.
I'm looking at the turbocache as Stephen recommended, though I'm not
certain it's actually grabbing system memory. From what (I thought) I
understood about TC, that's not applicable to non-integrated chipsets,
where IC's use system memory to compensate for lack on the gpu, and non
uses turbocache for extended memory on the board after a point (for
cards with massive memory, 768/1024mb). I'll look though, it's
something I hadn't considered or run into as a potential as of yet.
-mb
On Thu, 2009-08-06 at 16:01 +0000,
nadimhoque@gmail.com wrote:
> When you say nvidia proprietary drivers do you mean the one ubuntu gives or the one on the website. If you used the ubuntu given one uninstall that and install the one straight from the website. If you don't mind me asking what video cards do you have?
> Sent via BlackBerry from T-Mobile
>
> -----Original Message-----
> From: Stephen <cryptworks@gmail.com>
>
> Date: Thu, 6 Aug 2009 08:51:32
> To: <michael@butash.net>; Main PLUG discussion list<plug-discuss@lists.plug.phoenix.az.us>
> Subject: Re: Memory leaks in Ubuntu?
>
>
> i know all nvidia cards have a "turbo Cache" option to swipe some
> system memory for graphics rendering it may be that the driver is
> grabbing this and not releaseing it back.. this may be the killer.
>
> how to resolve. i am not sure.
>
> On Wed, Aug 5, 2009 at 8:46 PM, Michael Butash<michael@butash.net> wrote:
> > True enough it is tied to caching, but the fact it's marked as inactive
> > when I can definitely attribute application termination from lack of
> > memory is what I note as a problem. The system does not give this back
> > in the way of virtual or physical memory. The system does however
> > behave well enough as long as physical memory is present to give, but
> > watching a graph of the physical memory is *like* watching a memory
> > leak, whether it properly is or isn't, and end of the road is definitely
> > noticeable with performance on said system.
> >
> > Here's what a normal vmstat looks like currently, notice the caching:
> >
> > procs -----------memory---------- ---swap-- -----io---- -system--
> > ----cpu----
> > r b swpd free buff cache si so bi bo in cs us sy
> > id wa
> > 0 0 4096 224988 69472 5676224 0 0 2 31 12 41 7 6
> > 86 1
> >
> > Here's what vmstat -a looks like currently with "inact" having most:
> >
> > mb@thrawn:~$ vmstat -a
> > procs -----------memory---------- ---swap-- -----io---- -system--
> > ----cpu----
> > r b swpd free inact active si so bi bo in cs us sy
> > id wa
> > 2 0 4096 223196 5737708 1900724 0 0 2 31 12 41 7
> > 6 86 1
> >
> > Physical memory has nothing with free -m:
> >
> > total used free shared buffers
> > cached
> > Mem: 7888 7673 214 0 68
> > 5543
> > -/+ buffers/cache: 2062 5826
> > Swap: 1023 4 1019
> >
> > When it loses all physical memory, the system slows waay down, java apps
> > get weird (jbidwatcher is the java cancer for me), anything rendering
> > video won't scale, my gl screensaver bogs waaay down. Totem, vlc, or
> > other will simply just crash if run long enough in this state, but I
> > haven't caught the segfault or anything.
> >
> > I've used just about any build within the past 4 years or so of the NV
> > proprietary drivers, and nothing resolves it, though many have said
> > there are issues with 64bit. I can't attribute anything to actually
> > using the memory, and typically where I've seen leaks like this I can
> > always find something even in excess processes running away or ipc
> > threading even.
> >
> > I've lived with it so long it's just just *there*, but I'd kill to fix
> > whatever the heck it is. No amount of research has ever resulted in a
> > fix for me.
> >
> > Thanks for the input!
> >
> > -mb
> >
> >
> > On Wed, 2009-08-05 at 20:19 -0700, Joseph Sinclair wrote:
> >> I have had major problems with the NVidia proprietary drivers, particularly with Ubuntu 9.04. It seems like NVidia introduced a ton of REALLY bad bugs when they had to almost rewrite the drivers for the changes in the new XOrg server.
> >> I haven't seen the memory behavior you describe, but have you checked to be certain this isn't buffers and/or cache memory? I know all of my machines running any desktop distro tend to slowly accumulate cache until me
> >> mory is "full", but none of them have performance issues, since the kernel just reclaims cache LRU when it needs the RAM back. I also see fairly large amounts of "inactive" memory, but I never seem to have problems with the system reclaiming that as needed.
> >>
> >>
> >> Michael Butash wrote:
> >> > Has anyone else seen or experienced persistent memory leaks with ubuntu
> >> > 32bit or 64? I've literally had issues with it that may or may not be
> >> > particularly ubuntu issues back to 7.04 that I first noticed. The only
> >> > thing really in common system-wise is the hardware, and I somewhat
> >> > suspect it's Nvidia driver related, but nothing really indicates any
> >> > particular app. My primary desktop I use heavily just about anything,
> >> > but I have another system that's sole purpose is to play movies and
> >> > music on my TV I do almost nothing with that experiences the same
> >> > issues, NVidia card as well. With compiz or without this happens. Only
> >> > thing I haven't tried is running the NV drivers, but I rely on the
> >> > acceleration far too much on both systems.
> >> >
> >> > What I have noticed is there are no direct applications hogging memory
> >> > via top, rather it seems virtual memory ends up simply taking over all
> >> > physical memory and keeping it as "inactive" via "vmstat -a". Signs of
> >> > this include firefox flipping out, rendering/scaling video larger than
> >> > default, and just anything else that requires excessive memory use
> >> > having issues. I graph my physical memory usage via snmp, and I can
> >> > pretty accurately gauge how long I have until I need to do a hard reboot
> >> > to reclaim the "inactive" memory. It mostly works even memory starved
> >> > in this condition, just limits my usage, and even restarting x doesn't
> >> > help. Interestingly enough, neither system ever swaps at all...
> >> >
> >> > Has anyone successfully ever dealt with an issue like this killing
> >> > virtual memory? I really can't imagine I'm the only one... I've hunted
> >> > far and wide of the great interweb for a way to release the "inactive"
> >> > memory, as I'd even just go so far as to purge it once a day via cron if
> >> > I had to, but I can find nothing of forcefully clearing inactive/dirty
> >> > virtual memory space. I've seen others complain of the same behavior,
> >> > but have only seen the same rhetoric that "trust linux virtual memory
> >> > behavior, that's what it's supposed to do". Act like a stupid windoze
> >> > me install and reboot daily? I think not...
> >> >
> >> > -mb
> >> >
> >> > ---------------------------------------------------
> >> > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> >> > To subscribe, unsubscribe, or to change your mail settings:
> >> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >> >
> >>
> >
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> > To subscribe, unsubscribe, or to change your mail settings:
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >
>
>
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)