X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

> 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.

Supermicro servers uses the Nuvoton WPCM450 BMC and it is off of that where
the Matrox G200eW resides (for the console/video output/display). (The
manual for the system has a copyright date of 2014, so it's fairly recent.
Their newer stuff uses Aspeed AST chips instead.)


> 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.

I perform computer aided engineering (CAE) analyses (so finite element
analysis (FEA) and computational fluid dynamics (CFD)).

What I have is a FEA case that I had set up some time ago that I now use as
a benchmark case because that case is well known to me and the results have
been well validated. I use it to assess both hardware (e.g. when I get new
hardware) and software (when new releases of the analysis software are
published) to make sure that hardware and software are both able to produce
the validated results.

As such, I have a shell script that I run where it will perform 16 runs
sequentially (of the validated model) (it is actually two models, two
solvers, two different types of contacts that are being used, and whether
the files are on a SSD or on a HDD).

I start the shell script via a terminal on the console and then it just
runs in the foreground, but nothing is being displayed. (The only reason
why anything is even shown is being ahead of the command that actually
executes the analysis, I have a time -p command in front of it.) If it
weren't for that, literally nothing would be output back to the terminal
window in the desktop/GUI environment.

Yes, I am using GNOME. (Not sure how and/or IF you can switch the default
GUI from GNOME to something else like KDE. GNOME was the option available
during the installation.)

The other way that run these analysis, I will actually start the graphical
analysis environment and I will actually open the model (graphically), and
click on the solve button, and it will have more stuff going on graphically
(e.g. periodic update showing the latest status of the run).

But that isn't what I am currently running right now. Right now, it is
still just the shell script running from the terminal window on the console.

I think that the slowdown is because the CPU now has to draw the
desktop/GUI using CPU cycles rather than the graphics adapter, regardless
of whether there are any "visual" updates. My theory is that the mere fact
that it has to draw it (and keep drawing/redrawing it at the refresh rate)
is taking up CPU cycles and that's causing the slowdown as it is stealing
CPU resources to do that (away from the actual numerical/computational
analysis).

I was trying to use ssh -Y (and cygwin/X), but people advised against it.
There was a suggestion for me to try and use Xvnc instead. I haven't tried
that yet. In another source online, (re: ssh -Y), they suggest using Xming
(source: https://www.redwireservices.com/remote-x11-for-linux-unix). I
haven't tried that yet either (but being that it is still ssh -Y, the
advice against doing that still stands regardless of whether I'm using
cygwin/X or Xming).

The presence of a GUI is required because for some use cases of the
analysis application, the analysis features/functionality is integrated
into their desktop application environment which requires the GUI to "kick
off"/initiate. (Please see this thread on the SuSE forums for a more
detailed explanation of that:
https://forums.suse.com/showthread.php?9728-memory-leak-issue/page5)

(That thread also talks about what the analysis software developer calls
that if I try to perform the analysis outside of the graphic environment,
it can cause a type 3 error state with respect to the integrated file
manager inside the desktop application such that there are now new files in
the project directories that the file manager doesn't recognize and
therefore; thinks they don't belong there. It puts the project out of sync
with its file manager - a part of the desktop application that's
responsible for making sure that the project data stays consistent.)

Hope that helps.

Thanks.

Sincerely,
Ewen


On Thu, Dec 7, 2017 at 1:30 PM, <xorg at pengaru.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20171207/ce529c95/attachment-0001.html>