X is consuming ~100 GiB of RAM(!)

[xorg at pengaru.com]

On Thu, Dec 07, 2017 at 11:22:30AM -0500, Ewen Chan wrote:
> Hi-Angel:
> 
> > Yes, now it should be using CPU for rendering.
> 
> Hmmm...I am not so sure if that was really what I want.
> 
> It just reminds me of the adage of where you fix a leak/problem at one
> part/section of a pipe, but then create another one problem somewhere else
> down the pipe.
> 
> > That's one more of beauties of open source
> 
> The thing that I can think of that would be even more beautiful than that
> would be if this didn't happen at all in the first place. :D
> 
> This "memory leak" or high consumption of memory from the subsystem that
> draws/renders the desktop/GUI doesn't happen at all with Windows no matter
> how many times I run the same analysis script.
> 
> My early subjective analysis (with this mgag200 blacklist) puts the time it
> takes to run the simulations now on par with Windows and Windows just
> worked (properly) like this from the get go.
> 
> People keep talking about great and wonderful Linux is, but this experience
> has been anything but.
> 
> I think that I've spent about as much time trying to find a resolution to
> this issue as I have had doing my actual analysis work.
> 
> Pros (for Linux): It's faster when it is running at runlevel 3.
> 
> Cons: Can't use the GUI (because if I blacklist the driver for runlevel 5,
> then the performance is about the same as it is in Windows, at which point,
> why not just use Windows? The set up of a Windows system to get it up and
> running to this same level/state is significantly faster.)
> 
> Such a pity really that this has the potential to be **A**, if not **THE**
> solution to this problem.
> 
> Hmmm....it's been interesting.
> 
> I can still try other stuff (like iomem=relaxed), both either with the
> mgag200 or without it.
> 

For the record, the mga driver is quite old, pre-dating x86_64 and
most of its life was even pre hardware 3D acceleration.  Prior to
these transitions Matrox Milleniums were some of the best supported
graphics cards in Linux/X.

It would not surprise me if the problem you're experiencing is a
relatively trivial bug in the mga driver on x86_64.  It's been
uncommon to have such a configuration AFAIK, frankly I was a little
surprised to see someone mentioning some modern G200 use case.

Now I'm curious, what exactly is it you're doing?  Is your task
actually using the GUI or is it a console thing running in a terminal
and scrolling output?  Is there any visual output at all during the
analysis?  Are you just using a heavyweight desktop shell like gnome
shell and that's what is contending for CPU now that it's
unaccelerated?

- If the slowdown is just due to scrolling terminal text, redirect
  output to a file rather than having X display it all realtime.

- If it's a fancy composited desktop environment hogging CPU when
  unaccelerated, try using something lightweight like xfce or twm.