Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Hi-Angel:

Actually, I tried running it with SLES12 SP2 (which would have a newer
kernel than SLES12 SP1) and the analysis software actually failed to run in
SLES12 SP2.

Tried it (not for this issue, just in general).

Didn't work.

The analysis software is not certified to run in SLES12 SP2, just as it is
not certified to run on the latest kernel. (The platform support
documention is listed by distro version, so whatever kernel comes with the
distro version is what the analysis software has been certfied to run on.)

I don't disagree with you that newer kernels comes with many benefits. But
when I can't guarantee its operation and the developer of the analysis
software doesn't support it beyond what they've published as supported
linux distros/versions in their platform support documentation - so if I
want to make sure that everything works per the developer of the analysis
software (as an end user), I would be advised to stay within what platforms
they have certified (and support, including kernels) because that is what
the analysis software developer can guarantee proper operation of their
software.

Believe me, if this was something that I was developing and/or have more
freedom and control over how it is developed, using the latest and greatest
technologies that would yield the greatest benefit would of course be the
best thing to do. But I don't have any say in it as an end user. And given
the number of versions/iterations of Linux kernels out there, it would be
physically impossible to persistently maintain and ensure that a software
that's 26 GB (when installed) will work persistently throughout the entire
software system for all of the kernel versions, as they are developed and
published.

That would be insane. There would be no end to the testing.

(Remember, my analysis script alone takes 4.5 days to run. Think about how
many kernels are available that's floating out there and now imagine that I
would have to test it against each of the kernels. And that's just in the
realm of mechanical engineering analysis domain. Doesn't include any other
engineering and/or physics domains.)

It's just not feasible nor practical for the analysis software developer to
do that.

Thanks.

Sincerely,
Ewen

On Fri, Dec 8, 2017 at 4:17 AM, Hi-Angel  wrote:

> On 7 December 2017 at 19:22, Ewen Chan  wrote:
> > Pros (for Linux): It's faster when it is running at runlevel 3.
>
> Oh, by the way, I forgot to mention — just a tiny detail you might be
> curious of. I'm pretty sure you're running some old kernel, however in
> every kernel release there's a bunch of improvements and refactoring
> across all subsystems — power/cpu schedulers, kernel drivers, memory
> management, etc. So by using a later kernel you could make your
> calculations even faster. For more details see this
> https://kernelnewbies.org/LinuxVersions
>
> There's also per-thread malloc cache in glibc-2.26 which improves
> results of some benchmarks too. In general, if you want more
> performance, running latest software is recommended.
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Hi-Angel]

On 7 December 2017 at 19:22, Ewen Chan  wrote:
> Pros (for Linux): It's faster when it is running at runlevel 3.

Oh, by the way, I forgot to mention — just a tiny detail you might be
curious of. I'm pretty sure you're running some old kernel, however in
every kernel release there's a bunch of improvements and refactoring
across all subsystems — power/cpu schedulers, kernel drivers, memory
management, etc. So by using a later kernel you could make your
calculations even faster. For more details see this
https://kernelnewbies.org/LinuxVersions

There's also per-thread malloc cache in glibc-2.26 which improves
results of some benchmarks too. In general, if you want more
performance, running latest software is recommended.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: 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,  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 

Re: X is consuming ~100 GiB of RAM(!)

[xorg]

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.
> 
> Hmmmit'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.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Felix Miata]

Ewen Chan composed on 2017-12-07 11:22 (UTC-0500):...

> 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

G200eW is an edge case gfxchip, not something kernel, Xorg and driver developers
use. Unless Matrox or those who do use the G200eW get involved with the devel
process, reporting problems as they notice them, you cannot expect decent, if
any, support.

As it turns out, there is one SUSE dev who has shown interest in the MGA driver
(see bug I already mentioned), but as long as you are using an old 
out-of-support
openSUSE version, trying to get him to help is a waste of time. Server 15.x and
kernel 3.12 are well past their support lives on openSUSE. If what you are 
actually
using is SLE, then you should be entitled to support from SLE.

WRT iomem=relaxed, to find out if it would help to use the modesetting driver 
for
this uncommon gfxchip, you will most likely either have to try it yourself, or 
find
the relative few other people who have tried using it, or ask Matrox, to find 
out
about support.

FWIW, I took a brief look at an openSUSE Tumbleweed installation last updated 9
months ago, and found the MGA driver at least usable with a G550, but the tools
aren't even recognizing it properly. Xorg.0.log reports the MGA driver is in 
fact
in use.

# grep RET /etc/os-release
PRETTY_NAME="openSUSE Tumbleweed"
# uname -a
Linux a-865 4.10.4-1-default #1 SMP Sat Mar 18 12:29:57 UTC 2017 (e2ef894) i686 
i686 i386 GNU/Linux
# inxi -G -c0
Graphics:  Card: Matrox Systems Millennium G550
   Display Server: X.org 1.19.2 drivers: (unloaded: 
modesetting,fbdev,vesa) FAILED: mga
   tty size: 139x49 Advanced Data:
# zypper --no-refresh se -si mga
Loading repository data...
Reading installed packages...

S | Name   | Type| Version   | Arch | Repository
--++-+---+--+---
i | xf86-video-mga | package | 1.6.5-1.1 | i586 | OSS
# xrandr | head -n9
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 400 x 300, current 1280 x 1024, maximum 1280 x 1024
default connected 1280x1024+0+0 0mm x 0mm
   1280x1024 75.00*   60.00
   1152x864  75.00
   1024x768  75.0060.0070.00
   1280x960  60.00
   960x720   60.00
   928x696   60.00
   896x672   60.00
#
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

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.

Hmmmit's been interesting.

I can still try other stuff (like iomem=relaxed), both either with the
mgag200 or without it.

Thanks.

Sincerely,
Ewen

On Thu, Dec 7, 2017 at 11:04 AM, Hi-Angel  wrote:

> Yes, now it should be using CPU for rendering. If you're eager to save
> some cycles, you could recompile both Xorg and Mesa with optimizations
> "-flto=2 -march=native -O3 -pipe -fno-stack-protector
> -fno-semantic-interposition -fmerge-all-constants". That's one more of
> beauties of open source :) That said, I don't know how hard it might
> be on SuSe. On Archlinux here we have ᴬᵁᴿ repository, and building
> e.g. mesa from source is as easy as a command "yaourt -S mesa-git".
>
> On 7 December 2017 at 18:36, Ewen Chan  wrote:
> > Hi-Angel:
> >
> > I'm just asking due to innate curiosity.
> >
> > But the other part of it is I am wondering if the other driver is using
> CPU
> > cycles to draw/render the display/(raster?).
> >
> > I am asking because in the analyis runs, they are taking longer to run
> than
> > they were before I blacklisted the mgag200 driver. (Granted it is still
> very
> > early in the entire script, but the early results would suggest that the
> > system might now be using the CPU to draw/render the screen (raster?)
> due to
> > the analysis runs now taking longer to complete (for each of the three
> out
> > of 16 runs that I have completed so far).
> >
> > Thanks.
> >
> > Sincerely,
> > Ewen
> >
> > On Thu, Dec 7, 2017 at 10:32 AM, Hi-Angel  wrote:
> >>
> >> Yeah, nice, it worked. As for what other driver in the output should
> >> accord to vesa or whatever that provides the basic functional of
> >> outputting to a monitor — sorry, I don't know, I hope somebody else
> >> here can tell it. I don't think it's important for our purposes
> >> though.
> >>
> >> On 7 December 2017 at 18:18, Ewen Chan  wrote:
> >> > Hi-Angel:
> >> >
> >> >> Have you rebuild initramfs after blacklisting by the way?
> >> >
> >> > So...I did what that thread (and the thread that it points to within
> >> > that
> >> > thread) says to do.
> >> >
> >> > Created blacklist.conf and then put in there:
> >> >
> >> > blacklist mgag200
> >> >
> >> > and then I ran dracut --regenerate-all --force and rebooted (per the
> >> > thread-inside-that-thread's instructions).
> >> >
> >> > (like I said, I'm a grossly underqualified sysadmin so I just do what
> "I
> >> > am
> >> > told" from those sources.)
> >> >
> >> >
> >> > Here is the output of lsmod:
> >> >
> >> > Module  Size  Used by
> >> > ebtable_filter 12827  0
> >> > ebtables   35009  1 ebtable_filter
> >> > ip6table_filter12815  0
> >> > ip6_tables 27025  1 ip6table_filter
> >> > iptable_filter 12810  0
> >> > ip_tables  27239  1 iptable_filter
> >> > x_tables   34059  5
> >> > ip6table_filter,ip_tables,iptable_filter,ebtables,ip6_tables
> >> > af_packet  39847  0
> >> > fuse   95758  3
> >> > iscsi_ibft 12862  0
> >> > iscsi_boot_sysfs   16051  1 iscsi_ibft
> >> > raw13091  0
> >> > msr12865  0
> >> > joydev 17344  0
> >> > iTCO_wdt   13480  0
> >> > iTCO_vendor_support13718  1 iTCO_wdt
> >> > dm_mod110780  0
> >> > intel_rapl 18783  0
> >> > 

Re: X is consuming ~100 GiB of RAM(!)

[Hi-Angel]

Yes, now it should be using CPU for rendering. If you're eager to save
some cycles, you could recompile both Xorg and Mesa with optimizations
"-flto=2 -march=native -O3 -pipe -fno-stack-protector
-fno-semantic-interposition -fmerge-all-constants". That's one more of
beauties of open source :) That said, I don't know how hard it might
be on SuSe. On Archlinux here we have ᴬᵁᴿ repository, and building
e.g. mesa from source is as easy as a command "yaourt -S mesa-git".

On 7 December 2017 at 18:36, Ewen Chan  wrote:
> Hi-Angel:
>
> I'm just asking due to innate curiosity.
>
> But the other part of it is I am wondering if the other driver is using CPU
> cycles to draw/render the display/(raster?).
>
> I am asking because in the analyis runs, they are taking longer to run than
> they were before I blacklisted the mgag200 driver. (Granted it is still very
> early in the entire script, but the early results would suggest that the
> system might now be using the CPU to draw/render the screen (raster?) due to
> the analysis runs now taking longer to complete (for each of the three out
> of 16 runs that I have completed so far).
>
> Thanks.
>
> Sincerely,
> Ewen
>
> On Thu, Dec 7, 2017 at 10:32 AM, Hi-Angel  wrote:
>>
>> Yeah, nice, it worked. As for what other driver in the output should
>> accord to vesa or whatever that provides the basic functional of
>> outputting to a monitor — sorry, I don't know, I hope somebody else
>> here can tell it. I don't think it's important for our purposes
>> though.
>>
>> On 7 December 2017 at 18:18, Ewen Chan  wrote:
>> > Hi-Angel:
>> >
>> >> Have you rebuild initramfs after blacklisting by the way?
>> >
>> > So...I did what that thread (and the thread that it points to within
>> > that
>> > thread) says to do.
>> >
>> > Created blacklist.conf and then put in there:
>> >
>> > blacklist mgag200
>> >
>> > and then I ran dracut --regenerate-all --force and rebooted (per the
>> > thread-inside-that-thread's instructions).
>> >
>> > (like I said, I'm a grossly underqualified sysadmin so I just do what "I
>> > am
>> > told" from those sources.)
>> >
>> >
>> > Here is the output of lsmod:
>> >
>> > Module  Size  Used by
>> > ebtable_filter 12827  0
>> > ebtables   35009  1 ebtable_filter
>> > ip6table_filter12815  0
>> > ip6_tables 27025  1 ip6table_filter
>> > iptable_filter 12810  0
>> > ip_tables  27239  1 iptable_filter
>> > x_tables   34059  5
>> > ip6table_filter,ip_tables,iptable_filter,ebtables,ip6_tables
>> > af_packet  39847  0
>> > fuse   95758  3
>> > iscsi_ibft 12862  0
>> > iscsi_boot_sysfs   16051  1 iscsi_ibft
>> > raw13091  0
>> > msr12865  0
>> > joydev 17344  0
>> > iTCO_wdt   13480  0
>> > iTCO_vendor_support13718  1 iTCO_wdt
>> > dm_mod110780  0
>> > intel_rapl 18783  0
>> > intel_powerclamp   14690  0
>> > coretemp   13435  0
>> > kvm_intel 151399  0
>> > kvm   496652  1 kvm_intel
>> > crct10dif_pclmul   14307  0
>> > crc32_pclmul   13133  0
>> > crc32c_intel   22094  0
>> > pcspkr 12718  0
>> > sb_edac26894  0
>> > edac_core  66438  1 sb_edac
>> > igb   204492  0
>> > ptp18933  1 igb
>> > i2c_i801   22557  0
>> > pps_core   19333  1 ptp
>> > ipmi_si57482  0
>> > i2c_algo_bit   13413  1 igb
>> > ipmi_msghandler49676  1 ipmi_si
>> > mei_me 18355  0
>> > wmi19193  0
>> > mei86782  1 mei_me
>> > lpc_ich21093  0
>> > ioatdma71777  0
>> > mfd_core   13435  1 lpc_ich
>> > shpchp 32951  0
>> > dca15130  2 igb,ioatdma
>> > processor  44678  0
>> > button 13971  0
>> > hid_generic12559  0
>> > usbhid 52573  0
>> > btrfs1022893  2
>> > xor21411  1 btrfs
>> > raid6_pq  101908  1 btrfs
>> > sd_mod 50160  4
>> > ghash_clmulni_intel13230  0
>> > aesni_intel52860  0
>> > isci  149868  0
>> > aes_x86_64 17131  1 aesni_intel
>> > glue_helper13990  1 aesni_intel
>> > lrw13286  1 aesni_intel
>> > gf128mul   14951  1 lrw
>> > ablk_helper13597  1 aesni_intel
>> > cryptd 16263  3
>> > ghash_clmulni_intel,aesni_intel,ablk_helper
>> > ehci_pci   12914  0
>> > libsas 87336  1 isci
>> > ehci_hcd   79237  1 ehci_pci
>> > ahci   29929  2
>> > scsi_transport_sas 45130  2 isci,libsas

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Hi-Angel:

I'm just asking due to innate curiosity.

But the other part of it is I am wondering if the other driver is using CPU
cycles to draw/render the display/(raster?).

I am asking because in the analyis runs, they are taking longer to run than
they were before I blacklisted the mgag200 driver. (Granted it is still
very early in the entire script, but the early results would suggest that
the system might now be using the CPU to draw/render the screen (raster?)
due to the analysis runs now taking longer to complete (for each of the
three out of 16 runs that I have completed so far).

Thanks.

Sincerely,
Ewen

On Thu, Dec 7, 2017 at 10:32 AM, Hi-Angel  wrote:

> Yeah, nice, it worked. As for what other driver in the output should
> accord to vesa or whatever that provides the basic functional of
> outputting to a monitor — sorry, I don't know, I hope somebody else
> here can tell it. I don't think it's important for our purposes
> though.
>
> On 7 December 2017 at 18:18, Ewen Chan  wrote:
> > Hi-Angel:
> >
> >> Have you rebuild initramfs after blacklisting by the way?
> >
> > So...I did what that thread (and the thread that it points to within that
> > thread) says to do.
> >
> > Created blacklist.conf and then put in there:
> >
> > blacklist mgag200
> >
> > and then I ran dracut --regenerate-all --force and rebooted (per the
> > thread-inside-that-thread's instructions).
> >
> > (like I said, I'm a grossly underqualified sysadmin so I just do what "I
> am
> > told" from those sources.)
> >
> >
> > Here is the output of lsmod:
> >
> > Module  Size  Used by
> > ebtable_filter 12827  0
> > ebtables   35009  1 ebtable_filter
> > ip6table_filter12815  0
> > ip6_tables 27025  1 ip6table_filter
> > iptable_filter 12810  0
> > ip_tables  27239  1 iptable_filter
> > x_tables   34059  5
> > ip6table_filter,ip_tables,iptable_filter,ebtables,ip6_tables
> > af_packet  39847  0
> > fuse   95758  3
> > iscsi_ibft 12862  0
> > iscsi_boot_sysfs   16051  1 iscsi_ibft
> > raw13091  0
> > msr12865  0
> > joydev 17344  0
> > iTCO_wdt   13480  0
> > iTCO_vendor_support13718  1 iTCO_wdt
> > dm_mod110780  0
> > intel_rapl 18783  0
> > intel_powerclamp   14690  0
> > coretemp   13435  0
> > kvm_intel 151399  0
> > kvm   496652  1 kvm_intel
> > crct10dif_pclmul   14307  0
> > crc32_pclmul   13133  0
> > crc32c_intel   22094  0
> > pcspkr 12718  0
> > sb_edac26894  0
> > edac_core  66438  1 sb_edac
> > igb   204492  0
> > ptp18933  1 igb
> > i2c_i801   22557  0
> > pps_core   19333  1 ptp
> > ipmi_si57482  0
> > i2c_algo_bit   13413  1 igb
> > ipmi_msghandler49676  1 ipmi_si
> > mei_me 18355  0
> > wmi19193  0
> > mei86782  1 mei_me
> > lpc_ich21093  0
> > ioatdma71777  0
> > mfd_core   13435  1 lpc_ich
> > shpchp 32951  0
> > dca15130  2 igb,ioatdma
> > processor  44678  0
> > button 13971  0
> > hid_generic12559  0
> > usbhid 52573  0
> > btrfs1022893  2
> > xor21411  1 btrfs
> > raid6_pq  101908  1 btrfs
> > sd_mod 50160  4
> > ghash_clmulni_intel13230  0
> > aesni_intel52860  0
> > isci  149868  0
> > aes_x86_64 17131  1 aesni_intel
> > glue_helper13990  1 aesni_intel
> > lrw13286  1 aesni_intel
> > gf128mul   14951  1 lrw
> > ablk_helper13597  1 aesni_intel
> > cryptd 16263  3 ghash_clmulni_intel,aesni_
> intel,ablk_helper
> > ehci_pci   12914  0
> > libsas 87336  1 isci
> > ehci_hcd   79237  1 ehci_pci
> > ahci   29929  2
> > scsi_transport_sas 45130  2 isci,libsas
> > libahci36105  1 ahci
> > usbcore   254961  3 ehci_hcd,ehci_pci,usbhid
> > libata244519  3 ahci,libahci,libsas
> > usb_common 13057  1 usbcore
> > sg 40629  0
> > scsi_mod  244588  6
> > sg,isci,scsi_transport_sas,libata,libsas,sd_mod
> > autofs442930  2
> >
> > Out of that list, I don't see mgag200 there, but then again, I also don't
> > see any module that I recognize as being a "video driver" either.
> >
> > I hope that helps answer your questions(? 0.o?)
> >
> > Thanks.
> >
> > Sincerely,
> > Ewen
> >
> >
> > On Thu, Dec 7, 2017 at 1:46 AM, Hi-Angel 

Re: X is consuming ~100 GiB of RAM(!)

[Hi-Angel]

Yeah, nice, it worked. As for what other driver in the output should
accord to vesa or whatever that provides the basic functional of
outputting to a monitor — sorry, I don't know, I hope somebody else
here can tell it. I don't think it's important for our purposes
though.

On 7 December 2017 at 18:18, Ewen Chan  wrote:
> Hi-Angel:
>
>> Have you rebuild initramfs after blacklisting by the way?
>
> So...I did what that thread (and the thread that it points to within that
> thread) says to do.
>
> Created blacklist.conf and then put in there:
>
> blacklist mgag200
>
> and then I ran dracut --regenerate-all --force and rebooted (per the
> thread-inside-that-thread's instructions).
>
> (like I said, I'm a grossly underqualified sysadmin so I just do what "I am
> told" from those sources.)
>
>
> Here is the output of lsmod:
>
> Module  Size  Used by
> ebtable_filter 12827  0
> ebtables   35009  1 ebtable_filter
> ip6table_filter12815  0
> ip6_tables 27025  1 ip6table_filter
> iptable_filter 12810  0
> ip_tables  27239  1 iptable_filter
> x_tables   34059  5
> ip6table_filter,ip_tables,iptable_filter,ebtables,ip6_tables
> af_packet  39847  0
> fuse   95758  3
> iscsi_ibft 12862  0
> iscsi_boot_sysfs   16051  1 iscsi_ibft
> raw13091  0
> msr12865  0
> joydev 17344  0
> iTCO_wdt   13480  0
> iTCO_vendor_support13718  1 iTCO_wdt
> dm_mod110780  0
> intel_rapl 18783  0
> intel_powerclamp   14690  0
> coretemp   13435  0
> kvm_intel 151399  0
> kvm   496652  1 kvm_intel
> crct10dif_pclmul   14307  0
> crc32_pclmul   13133  0
> crc32c_intel   22094  0
> pcspkr 12718  0
> sb_edac26894  0
> edac_core  66438  1 sb_edac
> igb   204492  0
> ptp18933  1 igb
> i2c_i801   22557  0
> pps_core   19333  1 ptp
> ipmi_si57482  0
> i2c_algo_bit   13413  1 igb
> ipmi_msghandler49676  1 ipmi_si
> mei_me 18355  0
> wmi19193  0
> mei86782  1 mei_me
> lpc_ich21093  0
> ioatdma71777  0
> mfd_core   13435  1 lpc_ich
> shpchp 32951  0
> dca15130  2 igb,ioatdma
> processor  44678  0
> button 13971  0
> hid_generic12559  0
> usbhid 52573  0
> btrfs1022893  2
> xor21411  1 btrfs
> raid6_pq  101908  1 btrfs
> sd_mod 50160  4
> ghash_clmulni_intel13230  0
> aesni_intel52860  0
> isci  149868  0
> aes_x86_64 17131  1 aesni_intel
> glue_helper13990  1 aesni_intel
> lrw13286  1 aesni_intel
> gf128mul   14951  1 lrw
> ablk_helper13597  1 aesni_intel
> cryptd 16263  3 ghash_clmulni_intel,aesni_intel,ablk_helper
> ehci_pci   12914  0
> libsas 87336  1 isci
> ehci_hcd   79237  1 ehci_pci
> ahci   29929  2
> scsi_transport_sas 45130  2 isci,libsas
> libahci36105  1 ahci
> usbcore   254961  3 ehci_hcd,ehci_pci,usbhid
> libata244519  3 ahci,libahci,libsas
> usb_common 13057  1 usbcore
> sg 40629  0
> scsi_mod  244588  6
> sg,isci,scsi_transport_sas,libata,libsas,sd_mod
> autofs442930  2
>
> Out of that list, I don't see mgag200 there, but then again, I also don't
> see any module that I recognize as being a "video driver" either.
>
> I hope that helps answer your questions(? 0.o?)
>
> Thanks.
>
> Sincerely,
> Ewen
>
>
> On Thu, Dec 7, 2017 at 1:46 AM, Hi-Angel  wrote:
>>
>> Don't worry, I don't believe in Laplace's demon, and hence I believe
>> everybody don't know something.
>>
>> Tbh I'm not sure if the output of lspci implies the module is still
>> loaded, although I would assume it still is. Either way, to be sure
>> you can use `lsmod` command, it lists all currently loaded modules.
>> Have you rebuild initramfs after blacklisting by the way?
>>
>> On 7 December 2017 at 08:32, Ewen Chan  wrote:
>> > Stupid question though (again, I'm a grossly underqualified sysadmin).
>> >
>> > How can I tell if the blacklisting worked correctly?
>> >
>> > When I type in:
>> >
>> > # lspci -v | more
>> >
>> > this is what it outputs for the VGA section:
>> >
>> > 08:01.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA
>> > G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])
>> > Subsystem: Super Micro Computer Inc Device 062f

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

P.S.

I'm neither a dev nor all that familiar with this stuff either.

I'm just a user. And I've been on the SuSE forums talking with those people
in trying to figure out this issue that I am seeing where Xorg was
consuming ~100 GiB of RAM which, pretty much every technical person I've
talked to so far, doesn't think that should be happening at all.

And LOTS of people who I am talked to already are stumped as to why. So,
here I am.

And I/we are trying a bunch of different things to see if anything will
permanently alleviate this issue.

(Surprised that it is still happening at all, but *shrug*. Oh well.)

The Matrox framebuffer is popular on servers (console) because it's
presumably rather inexpensive and "lightweight". (akin to the old ATI 8 MB
Radeon framebuffers/Aspeed AST framebuffers)

They provide very basic video output capabilities for the console.

Thanks.

On Thu, Dec 7, 2017 at 1:05 AM, Felix Miata  wrote:

> Ewen Chan composed on 2017-12-07 00:32 (UTC-0500):
>
> > 08:01.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA
> > G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])
>  Seeing this thread get so long makes me curious. I'm neither dev nor all
> that
> familiar with the intricacies of Xorg or drivers, but I have had troubling
> experience with openSUSE and the mga driver, which you can see by looking
> at:
> https://bugzilla.opensuse.org/show_bug.cgi?id=1004453
>
> I wonder if it would be worth giving
>
> iomem=relaxed
>
> on cmdline a try?
>
> Reading the bug might provide other clues what to try.
>
> IIRC, most distros have abandoned providing any mga driver. Also I wonder
> if the
> G200eW driver might have support in the server-integrated modesetting
> driver?
> --
> "Wisdom is supreme; therefore get wisdom. Whatever else you
> get, get wisdom." Proverbs 4:7 (New Living Translation)
>
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
>
> Felix Miata  ***  http://fm.no-ip.com/
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Felix:

I might be able to try that.

It'll probably be the better part of a week before I will get around to
testing that (only because my analysis script need to load the system
significantly enough in order to trigger this issue).

In regards to your question at the end, someone else who is more
knowledgeable about this stuff than I am will have to take/field that one.

I have no idea.

Thanks.

Sincerely,
Ewen

On Thu, Dec 7, 2017 at 1:05 AM, Felix Miata  wrote:

> Ewen Chan composed on 2017-12-07 00:32 (UTC-0500):
>
> > 08:01.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA
> > G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])
>  Seeing this thread get so long makes me curious. I'm neither dev nor all
> that
> familiar with the intricacies of Xorg or drivers, but I have had troubling
> experience with openSUSE and the mga driver, which you can see by looking
> at:
> https://bugzilla.opensuse.org/show_bug.cgi?id=1004453
>
> I wonder if it would be worth giving
>
> iomem=relaxed
>
> on cmdline a try?
>
> Reading the bug might provide other clues what to try.
>
> IIRC, most distros have abandoned providing any mga driver. Also I wonder
> if the
> G200eW driver might have support in the server-integrated modesetting
> driver?
> --
> "Wisdom is supreme; therefore get wisdom. Whatever else you
> get, get wisdom." Proverbs 4:7 (New Living Translation)
>
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
>
> Felix Miata  ***  http://fm.no-ip.com/
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Hi-Angel:

> Have you rebuild initramfs after blacklisting by the way?

So...I did what that thread (and the thread that it points to within that
thread) says to do.

Created blacklist.conf and then put in there:

blacklist mgag200

and then I ran dracut --regenerate-all --force and rebooted (per the
thread-inside-that-thread's instructions).

(like I said, I'm a grossly underqualified sysadmin so I just do what "I am
told" from those sources.)


Here is the output of lsmod:

Module  Size  Used by
ebtable_filter 12827  0
ebtables   35009  1 ebtable_filter
ip6table_filter12815  0
ip6_tables 27025  1 ip6table_filter
iptable_filter 12810  0
ip_tables  27239  1 iptable_filter
x_tables   34059  5
ip6table_filter,ip_tables,iptable_filter,ebtables,ip6_tables
af_packet  39847  0
fuse   95758  3
iscsi_ibft 12862  0
iscsi_boot_sysfs   16051  1 iscsi_ibft
raw13091  0
msr12865  0
joydev 17344  0
iTCO_wdt   13480  0
iTCO_vendor_support13718  1 iTCO_wdt
dm_mod110780  0
intel_rapl 18783  0
intel_powerclamp   14690  0
coretemp   13435  0
kvm_intel 151399  0
kvm   496652  1 kvm_intel
crct10dif_pclmul   14307  0
crc32_pclmul   13133  0
crc32c_intel   22094  0
pcspkr 12718  0
sb_edac26894  0
edac_core  66438  1 sb_edac
igb   204492  0
ptp18933  1 igb
i2c_i801   22557  0
pps_core   19333  1 ptp
ipmi_si57482  0
i2c_algo_bit   13413  1 igb
ipmi_msghandler49676  1 ipmi_si
mei_me 18355  0
wmi19193  0
mei86782  1 mei_me
lpc_ich21093  0
ioatdma71777  0
mfd_core   13435  1 lpc_ich
shpchp 32951  0
dca15130  2 igb,ioatdma
processor  44678  0
button 13971  0
hid_generic12559  0
usbhid 52573  0
btrfs1022893  2
xor21411  1 btrfs
raid6_pq  101908  1 btrfs
sd_mod 50160  4
ghash_clmulni_intel13230  0
aesni_intel52860  0
isci  149868  0
aes_x86_64 17131  1 aesni_intel
glue_helper13990  1 aesni_intel
lrw13286  1 aesni_intel
gf128mul   14951  1 lrw
ablk_helper13597  1 aesni_intel
cryptd 16263  3 ghash_clmulni_intel,aesni_intel,ablk_helper
ehci_pci   12914  0
libsas 87336  1 isci
ehci_hcd   79237  1 ehci_pci
ahci   29929  2
scsi_transport_sas 45130  2 isci,libsas
libahci36105  1 ahci
usbcore   254961  3 ehci_hcd,ehci_pci,usbhid
libata244519  3 ahci,libahci,libsas
usb_common 13057  1 usbcore
sg 40629  0
scsi_mod  244588  6
sg,isci,scsi_transport_sas,libata,libsas,sd_mod
autofs442930  2

Out of that list, I don't see mgag200 there, but then again, I also don't
see any module that I recognize as being a "video driver" either.

I hope that helps answer your questions(? 0.o?)

Thanks.

Sincerely,
Ewen


On Thu, Dec 7, 2017 at 1:46 AM, Hi-Angel  wrote:

> Don't worry, I don't believe in Laplace's demon, and hence I believe
> everybody don't know something.
>
> Tbh I'm not sure if the output of lspci implies the module is still
> loaded, although I would assume it still is. Either way, to be sure
> you can use `lsmod` command, it lists all currently loaded modules.
> Have you rebuild initramfs after blacklisting by the way?
>
> On 7 December 2017 at 08:32, Ewen Chan  wrote:
> > Stupid question though (again, I'm a grossly underqualified sysadmin).
> >
> > How can I tell if the blacklisting worked correctly?
> >
> > When I type in:
> >
> > # lspci -v | more
> >
> > this is what it outputs for the VGA section:
> >
> > 08:01.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA
> > G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])
> > Subsystem: Super Micro Computer Inc Device 062f
> > Flags: bus master, medium devsel, latency 64, IRQ 11
> > Memory at dd00 (32-bit, prefetchable) [size=16M]
> > Memory at df80 (32-bit, non-prefetchable) [size=16K]
> > Memory at df00 (32-bit, non-prefetchable) [size=8M]
> > Expansion ROM at  [disabled]
> > Capabilities: [dc] Power Management version 1
> > Kernel modules: mgag200
> >
> > Is there another way to confirm that the blacklisting did what it was
> > supposed to?
> >
> > Thanks.
> >
> > On Wed, Dec 6, 2017 at 11:39 PM, Hi-Angel 

Re: X is consuming ~100 GiB of RAM(!)

[Michel Dänzer]

[ Dropping x...@freedesktop.org from Cc, one copy of each list post is
enough :) ]

On 2017-12-07 05:39 AM, Hi-Angel wrote:
> 
> You know, btw, another silly idea: if blacklisting the driver will 
> help, but you actually care of graphics performance — you could try 
> enabling it back, and then installing modesetting driver, and
> forcing Xorg to use it through a xorg.conf.

The modesetting driver only works with a KMS kernel driver. Ewen
currently cannot be using a KMS kernel driver, otherwise the Xorg mga
driver couldn't work. If he was using a KMS kernel driver, Xorg would
automatically use the modesetting driver.


> Per my understanding the leak could specifically be in Matrox DDX
> driver — if this is the case, by replacing it with modesetting DDX
> you'd keep the performance and get rid of leaks. "modesetting" is a
> vendor-neutral DDX driver which is implemented on top of whatever
> driver provides OpenGL functional.

The modesetting driver can only provide hardware acceleration via
glamor, which requires decent EGL and OpenGL support, which is unlikely
to exist for this GPU.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Hi-Angel]

Don't worry, I don't believe in Laplace's demon, and hence I believe
everybody don't know something.

Tbh I'm not sure if the output of lspci implies the module is still
loaded, although I would assume it still is. Either way, to be sure
you can use `lsmod` command, it lists all currently loaded modules.
Have you rebuild initramfs after blacklisting by the way?

On 7 December 2017 at 08:32, Ewen Chan  wrote:
> Stupid question though (again, I'm a grossly underqualified sysadmin).
>
> How can I tell if the blacklisting worked correctly?
>
> When I type in:
>
> # lspci -v | more
>
> this is what it outputs for the VGA section:
>
> 08:01.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA
> G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])
> Subsystem: Super Micro Computer Inc Device 062f
> Flags: bus master, medium devsel, latency 64, IRQ 11
> Memory at dd00 (32-bit, prefetchable) [size=16M]
> Memory at df80 (32-bit, non-prefetchable) [size=16K]
> Memory at df00 (32-bit, non-prefetchable) [size=8M]
> Expansion ROM at  [disabled]
> Capabilities: [dc] Power Management version 1
> Kernel modules: mgag200
>
> Is there another way to confirm that the blacklisting did what it was
> supposed to?
>
> Thanks.
>
> On Wed, Dec 6, 2017 at 11:39 PM, Hi-Angel  wrote:
>>
>> On 7 December 2017 at 06:19, Hi-Angel  wrote:
>> > On 7 December 2017 at 06:05, Ewen Chan  wrote:
>> >> Hi-Angel:
>> >>
>> >> Thank you for that!!!
>> >>
>> >> Two questions:
>> >>
>> >> 1) Will the commands from the CentOS distro work with SuSE?
>> >
>> > Well, the linked post doesn't show how to blacklist because it was
>> > created after the fact (author forgot to re-build initramfs). For an
>> > example of doing that you can refer e.g. this
>> > https://askubuntu.com/a/110343/266507 Except I am not sure how to
>> > rebuild initramfs on SuSe — on Archlinux I'm using it is `sudo
>> > mkinitcpio -p linux`.
>> >
>> >> 2) Do you think there will be problems using the VESA driver instead of
>> >> the
>> >> mgag200 driver? (i.e. the GUI/remote X/VNC would exhibit unexpected
>> >> behaviours?
>> >
>> > Nothing that I know of. You'd obviously get a lower graphics
>> > performance, but otherwise I think it should be fine.
>>
>> You know, btw, another silly idea: if blacklisting the driver will
>> help, but you actually care of graphics performance — you could try
>> enabling it back, and then installing modesetting driver, and forcing
>> Xorg to use it through a xorg.conf. Per my understanding the leak
>> could specifically be in Matrox DDX driver — if this is the case, by
>> replacing it with modesetting DDX you'd keep the performance and get
>> rid of leaks. "modesetting" is a vendor-neutral DDX driver which is
>> implemented on top of whatever driver provides OpenGL functional.
>>
>> It should be noted though that if leaks are in the matrox's provision
>> of OpenGL, it won't help.
>
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Felix Miata]

Ewen Chan composed on 2017-12-07 00:32 (UTC-0500):

> 08:01.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA
> G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])   
 Seeing this thread get so long makes me curious. I'm neither dev nor all that
familiar with the intricacies of Xorg or drivers, but I have had troubling
experience with openSUSE and the mga driver, which you can see by looking at:
https://bugzilla.opensuse.org/show_bug.cgi?id=1004453

I wonder if it would be worth giving

iomem=relaxed

on cmdline a try?

Reading the bug might provide other clues what to try.

IIRC, most distros have abandoned providing any mga driver. Also I wonder if the
G200eW driver might have support in the server-integrated modesetting driver?
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Stupid question though (again, I'm a grossly underqualified sysadmin).

How can I tell if the blacklisting worked correctly?

When I type in:

# lspci -v | more

this is what it outputs for the VGA section:

08:01.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA
G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])
Subsystem: Super Micro Computer Inc Device 062f
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at dd00 (32-bit, prefetchable) [size=16M]
Memory at df80 (32-bit, non-prefetchable) [size=16K]
Memory at df00 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at  [disabled]
Capabilities: [dc] Power Management version 1
Kernel modules: mgag200

Is there another way to confirm that the blacklisting did what it was
supposed to?

Thanks.

On Wed, Dec 6, 2017 at 11:39 PM, Hi-Angel  wrote:

> On 7 December 2017 at 06:19, Hi-Angel  wrote:
> > On 7 December 2017 at 06:05, Ewen Chan  wrote:
> >> Hi-Angel:
> >>
> >> Thank you for that!!!
> >>
> >> Two questions:
> >>
> >> 1) Will the commands from the CentOS distro work with SuSE?
> >
> > Well, the linked post doesn't show how to blacklist because it was
> > created after the fact (author forgot to re-build initramfs). For an
> > example of doing that you can refer e.g. this
> > https://askubuntu.com/a/110343/266507 Except I am not sure how to
> > rebuild initramfs on SuSe — on Archlinux I'm using it is `sudo
> > mkinitcpio -p linux`.
> >
> >> 2) Do you think there will be problems using the VESA driver instead of
> the
> >> mgag200 driver? (i.e. the GUI/remote X/VNC would exhibit unexpected
> >> behaviours?
> >
> > Nothing that I know of. You'd obviously get a lower graphics
> > performance, but otherwise I think it should be fine.
>
> You know, btw, another silly idea: if blacklisting the driver will
> help, but you actually care of graphics performance — you could try
> enabling it back, and then installing modesetting driver, and forcing
> Xorg to use it through a xorg.conf. Per my understanding the leak
> could specifically be in Matrox DDX driver — if this is the case, by
> replacing it with modesetting DDX you'd keep the performance and get
> rid of leaks. "modesetting" is a vendor-neutral DDX driver which is
> implemented on top of whatever driver provides OpenGL functional.
>
> It should be noted though that if leaks are in the matrox's provision
> of OpenGL, it won't help.
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Thanks.

I just tried the blacklisting right now so it will be some time (as I
re-run my tests) to find out whether that worked or not.

Thanks.

On Thu, Dec 7, 2017 at 12:17 AM, Ken Moffat  wrote:

> On Thu, Dec 07, 2017 at 07:39:27AM +0300, Hi-Angel wrote:
> > > On 7 December 2017 at 06:05, Ewen Chan  wrote:
> >
> > You know, btw, another silly idea: if blacklisting the driver will
> > help, but you actually care of graphics performance — you could try
> > enabling it back, and then installing modesetting driver, and forcing
> > Xorg to use it through a xorg.conf. Per my understanding the leak
> > could specifically be in Matrox DDX driver — if this is the case, by
> > replacing it with modesetting DDX you'd keep the performance and get
> > rid of leaks. "modesetting" is a vendor-neutral DDX driver which is
> > implemented on top of whatever driver provides OpenGL functional.
> >
> > It should be noted though that if leaks are in the matrox's provision
> > of OpenGL, it won't help.
>
> One possible problem with using modesetting in 1.15.2 is that it was
> recent, and sometimes regarded as experimental.  Nowadays it is
> built as part of the xorg-server (provided the dependencies are
> present), but I've no idea what SuSe did in that old version -
> generally they seem to make it hard for people not using their
> distros to find how they built the source.  So maybe using
> modesetting will fail - I hope not, because on one of my previous
> cheap machines it improved the CPU usage significantly when running
> X, so I now regard the modesetting driver as well worth having.
>
> ĸen
> --
> Truth, in front of her huge walk-in wardrobe, selected black leather
> boots with stiletto heels for such a barefaced truth.
>  - Unseen Academicals
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Ken Moffat]

On Thu, Dec 07, 2017 at 07:39:27AM +0300, Hi-Angel wrote:
> > On 7 December 2017 at 06:05, Ewen Chan  wrote:
> 
> You know, btw, another silly idea: if blacklisting the driver will
> help, but you actually care of graphics performance — you could try
> enabling it back, and then installing modesetting driver, and forcing
> Xorg to use it through a xorg.conf. Per my understanding the leak
> could specifically be in Matrox DDX driver — if this is the case, by
> replacing it with modesetting DDX you'd keep the performance and get
> rid of leaks. "modesetting" is a vendor-neutral DDX driver which is
> implemented on top of whatever driver provides OpenGL functional.
> 
> It should be noted though that if leaks are in the matrox's provision
> of OpenGL, it won't help.

One possible problem with using modesetting in 1.15.2 is that it was
recent, and sometimes regarded as experimental.  Nowadays it is
built as part of the xorg-server (provided the dependencies are
present), but I've no idea what SuSe did in that old version -
generally they seem to make it hard for people not using their
distros to find how they built the source.  So maybe using
modesetting will fail - I hope not, because on one of my previous
cheap machines it improved the CPU usage significantly when running
X, so I now regard the modesetting driver as well worth having.

ĸen
-- 
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
 - Unseen Academicals
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Hi-Angel]

On 7 December 2017 at 06:19, Hi-Angel  wrote:
> On 7 December 2017 at 06:05, Ewen Chan  wrote:
>> Hi-Angel:
>>
>> Thank you for that!!!
>>
>> Two questions:
>>
>> 1) Will the commands from the CentOS distro work with SuSE?
>
> Well, the linked post doesn't show how to blacklist because it was
> created after the fact (author forgot to re-build initramfs). For an
> example of doing that you can refer e.g. this
> https://askubuntu.com/a/110343/266507 Except I am not sure how to
> rebuild initramfs on SuSe — on Archlinux I'm using it is `sudo
> mkinitcpio -p linux`.
>
>> 2) Do you think there will be problems using the VESA driver instead of the
>> mgag200 driver? (i.e. the GUI/remote X/VNC would exhibit unexpected
>> behaviours?
>
> Nothing that I know of. You'd obviously get a lower graphics
> performance, but otherwise I think it should be fine.

You know, btw, another silly idea: if blacklisting the driver will
help, but you actually care of graphics performance — you could try
enabling it back, and then installing modesetting driver, and forcing
Xorg to use it through a xorg.conf. Per my understanding the leak
could specifically be in Matrox DDX driver — if this is the case, by
replacing it with modesetting DDX you'd keep the performance and get
rid of leaks. "modesetting" is a vendor-neutral DDX driver which is
implemented on top of whatever driver provides OpenGL functional.

It should be noted though that if leaks are in the matrox's provision
of OpenGL, it won't help.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Thanks.

I'll have to try that.

(The thread links to another CentOS thread that talks about how. I just
wasn't sure if the commands were a 1:1 match.)

On Wed, Dec 6, 2017 at 10:19 PM, Hi-Angel  wrote:

> On 7 December 2017 at 06:05, Ewen Chan  wrote:
> > Hi-Angel:
> >
> > Thank you for that!!!
> >
> > Two questions:
> >
> > 1) Will the commands from the CentOS distro work with SuSE?
>
> Well, the linked post doesn't show how to blacklist because it was
> created after the fact (author forgot to re-build initramfs). For an
> example of doing that you can refer e.g. this
> https://askubuntu.com/a/110343/266507 Except I am not sure how to
> rebuild initramfs on SuSe — on Archlinux I'm using it is `sudo
> mkinitcpio -p linux`.
>
> > 2) Do you think there will be problems using the VESA driver instead of
> the
> > mgag200 driver? (i.e. the GUI/remote X/VNC would exhibit unexpected
> > behaviours?
>
> Nothing that I know of. You'd obviously get a lower graphics
> performance, but otherwise I think it should be fine.
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Hi-Angel]

On 7 December 2017 at 06:05, Ewen Chan  wrote:
> Hi-Angel:
>
> Thank you for that!!!
>
> Two questions:
>
> 1) Will the commands from the CentOS distro work with SuSE?

Well, the linked post doesn't show how to blacklist because it was
created after the fact (author forgot to re-build initramfs). For an
example of doing that you can refer e.g. this
https://askubuntu.com/a/110343/266507 Except I am not sure how to
rebuild initramfs on SuSe — on Archlinux I'm using it is `sudo
mkinitcpio -p linux`.

> 2) Do you think there will be problems using the VESA driver instead of the
> mgag200 driver? (i.e. the GUI/remote X/VNC would exhibit unexpected
> behaviours?

Nothing that I know of. You'd obviously get a lower graphics
performance, but otherwise I think it should be fine.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Hi-Angel:

Thank you for that!!!

Two questions:

1) Will the commands from the CentOS distro work with SuSE?

2) Do you think there will be problems using the VESA driver instead of the
mgag200 driver? (i.e. the GUI/remote X/VNC would exhibit unexpected
behaviours?

Thanks.

Sincerely,
Ewen

On Wed, Dec 6, 2017 at 9:51 PM, Hi-Angel  wrote:

> On 7 December 2017 at 05:45, Hi-Angel  wrote:
> > On 6 December 2017 at 15:25, Vladimir Dergachev 
> wrote:
> >>
> >> Keep in mind that Xorg will show memory usage from mapping graphics
> memory..
> >> which could be large on your card.
> >>
> >> Also, are you using CUDA ?
> >
> > I don't think Matrox provides CUDA functional.
> >
> > @Ewen, by the way, this mail pushed me to another thought the leak
> > could possibly be in userspace driver — Matrox doesn't seem to use
> > Mesa, so I know basically nothing about them. I tried googling a bit,
> > and barely the first link is this
> > https://www.centos.org/forums/viewtopic.php?t=57699 "Xorg Memory Leak
> > with Matrox G200eR2".
> >
> > So yes, it is very well possible the leak not because of XServer, but
> > rather bug in Matrox's driver. In this case upgrading Xorg won't help,
> > you need to get support from Matrox.
>
> …and you can actually check whether it is true by following the same
> steps as the author of the forum post ↑ I.e. by blacklisting the
> driver, and checking if the problem fixed in software rendering.
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Hi-Angel]

On 7 December 2017 at 05:45, Hi-Angel  wrote:
> On 6 December 2017 at 15:25, Vladimir Dergachev  
> wrote:
>>
>> Keep in mind that Xorg will show memory usage from mapping graphics memory..
>> which could be large on your card.
>>
>> Also, are you using CUDA ?
>
> I don't think Matrox provides CUDA functional.
>
> @Ewen, by the way, this mail pushed me to another thought the leak
> could possibly be in userspace driver — Matrox doesn't seem to use
> Mesa, so I know basically nothing about them. I tried googling a bit,
> and barely the first link is this
> https://www.centos.org/forums/viewtopic.php?t=57699 "Xorg Memory Leak
> with Matrox G200eR2".
>
> So yes, it is very well possible the leak not because of XServer, but
> rather bug in Matrox's driver. In this case upgrading Xorg won't help,
> you need to get support from Matrox.

…and you can actually check whether it is true by following the same
steps as the author of the forum post ↑ I.e. by blacklisting the
driver, and checking if the problem fixed in software rendering.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Hi-Angel]

On 6 December 2017 at 15:25, Vladimir Dergachev  wrote:
>
> Keep in mind that Xorg will show memory usage from mapping graphics memory..
> which could be large on your card.
>
> Also, are you using CUDA ?

I don't think Matrox provides CUDA functional.

@Ewen, by the way, this mail pushed me to another thought the leak
could possibly be in userspace driver — Matrox doesn't seem to use
Mesa, so I know basically nothing about them. I tried googling a bit,
and barely the first link is this
https://www.centos.org/forums/viewtopic.php?t=57699 "Xorg Memory Leak
with Matrox G200eR2".

So yes, it is very well possible the leak not because of XServer, but
rather bug in Matrox's driver. In this case upgrading Xorg won't help,
you need to get support from Matrox.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Vladimir Dergachev]

Also, given the the high usage does not happen outside of gnome session, 
perhaps this is connected to compositing..


best

Vladimir Dergachev

On Wed, 6 Dec 2017, Hi-Angel wrote:


The troubleshooting link you provided states that the high memory
usage typically belongs to some other application. Sorry, I am just an
occasional bystander here, and can't tell much of technical details,
but I imagine it works like this(I hope someone will correct me on
details): an app requests, for example, a glx object, and XServer
allocates one. When the app is done with the object, it requests
XServer to deallocate it. The point is: although this memory accounted
on part of XServer process — it is actually owned by the app. The link
also states that you can use `xrestop` application to see the owners
and amounts of the memory.

On 5 December 2017 at 21:14, Ewen Chan  wrote:

To Whom It May Concern:

Hello everybody. My name is Ewen and I am new to this distribution list.

So let me start with a little bit of background and the problem statement of
what I am seeing/encountering.

I am running a SuperMicro Server 6027TR-HTRF
(https://www.supermicro.com/products/system/2u/6027/sys-6027tr-htrf.cfm)
(which uses a Matrox G200eW graphics chip and it has four half-width nodes,
each node has two processor, each processor is an Intel Xeon E5-2690 (v1)
(8-core, 2.9 GHz stock, HTT disabled) running SuSE Linux Enterprise Server
12 SP1 (SLES 12 SP1).

Here are some of the outputs from the system:

ewen@aes4:~> X -version

X.Org X Server 1.15.2
Release Date: 2014-06-27
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11
20:52:43 UTC 2015 (8d714a0) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.12.49-11-default
root=UUID=fc4dcdb9-2468-422c-b29f-8da42fd7dec0
resume=/dev/disk/by-uuid/1d5d8a9c-218e-4b66-b094-f5154ab08434 splash=silent
quit showopts crashkernel=123M,high crashkernel=72M,low
Build Date: 12 November 2015  01:23:55AM

Current version of pixman: 0.32.6
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
ewen@aes4:~> uname -a
Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015 (8d714a0)
x86_64 x86_64 x86_64 GNU/Linux

The problem that I am having is that I am running a CAE analysis application
and during the course of the run, X will eventually consume close to 100 GiB
of RAM (out of 125 GiB installed)

ewen@aes4:~> date
Tue Dec 5 05:08:28 EST 2017
ewen@aes4:~> ps aux | grep Xorg
root 2245 7.7 79.0 271100160 104332316 tty7 Ssl+ Nov25 1078:19 /usr/bin/Xorg
:0 -background none -verbose -auth /run/gdm/aut
h-for-gdm-9L7Ckz/database -seat seat0 -nolisten tcp vt7
ewen 11769 0.0 0.0 10500 944 pts/1 R+ 05:08 0:00 grep --color=auto Xorg

This does not occur when I perform the same analysis in runlevel 3 and when
I switch back to runlevel 5 and I am using GNOME for the desktop
environment, regardless of whether I initiate the analysis via a Terminal
inside GNOME or I ssh into the system (via cygwin from a Windows box), the
host server's X memory usage will continually increase as the analysis
progresses.

In trying to research this issue, I have found that I can either restrict
the amount of cache that X does via ulimit -m (Source:
https://wiki.ubuntu.com/X/Troubleshooting/HighMemory) or I can edit
xorg.conf by adding this option:

Option "XaaNoPixmapCache"

(Source: https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.xhtml)

Would that be the recommended solution to the problem that I am experiencing
with X?

A couple of other notes:

ewen@aes4:~> free -g
 total   used   free sharedbuffers cached
Mem:   125125  0  0  0  3
-/+ buffers/cache:122  3
Swap:  256170 85
ewen@aes4:~> cat /proc/sys/vm/vfs_cache_pressure
200

Your help and commentary would be greatly appreciated. Thank you.

Sincerely,

Ewen Chan

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Vladimir Dergachev]

Keep in mind that Xorg will show memory usage from mapping graphics 
memory.. which could be large on your card.


Also, are you using CUDA ?

best

Vladimir Dergachev

On Wed, 6 Dec 2017, Hi-Angel wrote:


Oh, wow, this looks like a Xorg bug then. I'd recommend trying latest Xorg then 
— yours one is 3 years old, hopefully it's something fixed. If it won't help, 
I'd recommend report a bug.
Although ulimit workaround worth a try, but If this is really a memory leak, I 
doubt it'd help much. What I think would happen is that Xorg won't be able to 
allocate resources on apps'
behalf, making apps to crash.

On 6 December 2017 at 00:49, Ewen Chan  wrote:
  Thank you, Hi-Angel.
I thought so too originally, but when I am launching the analysis via a 
terminal on the console (or even via ssh from cygwin into the system) and it is 
still exhibiting the same
behaviour despite the fact that there isn't any graphical component running 
beyond just runlevel 5 (and having GNOME running on X), issuing the ps aux 
command shows Xorg being the
culprit for the high memory consumption.

In trying to perform the forensic analysis, I would think that it would be true 
if there is a graphic component that's actually running, but there isn't 
(beyond runlevel
5/GNOME-on-X).

X is supposed to release the memory back into the available pool, but it 
doesn't -- it just keeps increasing.

So even after the application has terminated, if X doesn't release the memory 
back, then ps aux will show X as being the process that's holding the memory.

Again, the idea of providing the first link was to limit how much RAM can X use 
for the caching/retention (using ulimit -m somehow and editing 
/etc/security/limits.conf) and I raised
the question (on the SLES forum) how would I know what I should set the limit 
at? Too low and it will crash often. Too high, and I am back to this current 
problem that I am
experiencing now.


[IMAGE]


​(sorry that the output of xrestop above is a screenshot because I am twice 
remotely logged in (first to home system and then again via the IPMI to the 
console).)

xrestop only shows about 22 MiB.

ps aux | grep Xorg is still showing about 100 GiB tied to the Xorg process.

Thanks.

Sincerely,
Ewen


On Tue, Dec 5, 2017 at 4:28 PM, Hi-Angel  wrote:
  The troubleshooting link you provided states that the high memory
  usage typically belongs to some other application. Sorry, I am just an
  occasional bystander here, and can't tell much of technical details,
  but I imagine it works like this(I hope someone will correct me on
  details): an app requests, for example, a glx object, and XServer
  allocates one. When the app is done with the object, it requests
  XServer to deallocate it. The point is: although this memory accounted
  on part of XServer process — it is actually owned by the app. The link
  also states that you can use `xrestop` application to see the owners
  and amounts of the memory.

  On 5 December 2017 at 21:14, Ewen Chan  wrote:
  > To Whom It May Concern:
  >
  > Hello everybody. My name is Ewen and I am new to this distribution list.
  >
  > So let me start with a little bit of background and the problem 
statement of
  > what I am seeing/encountering.
  >
  > I am running a SuperMicro Server 6027TR-HTRF
  > (https://www.supermicro.com/products/system/2u/6027/sys-6027tr-htrf.cfm)
  > (which uses a Matrox G200eW graphics chip and it has four half-width 
nodes,
  > each node has two processor, each processor is an Intel Xeon E5-2690 
(v1)
  > (8-core, 2.9 GHz stock, HTT disabled) running SuSE Linux Enterprise 
Server
  > 12 SP1 (SLES 12 SP1).
  >
  > Here are some of the outputs from the system:
  >
  > ewen@aes4:~> X -version
  >
  > X.Org X Server 1.15.2
  > Release Date: 2014-06-27
  > X Protocol Version 11, Revision 0
  > Build Operating System: openSUSE SUSE LINUX
  > Current Operating System: Linux aes4 3.12.49-11-default #1 SMP Wed Nov 
11
  > 20:52:43 UTC 2015 (8d714a0) x86_64
  > Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.12.49-11-default
  > root=UUID=fc4dcdb9-2468-422c-b29f-8da42fd7dec0
  > resume=/dev/disk/by-uuid/1d5d8a9c-218e-4b66-b094-f5154ab08434 
splash=silent
  > quit showopts crashkernel=123M,high crashkernel=72M,low
  > Build Date: 12 November 2015  01:23:55AM
  >
  > Current version of pixman: 0.32.6
  >          Before reporting problems, check http://wiki.x.org
  >          to make sure that you have the latest version.
  > ewen@aes4:~> uname -a
  > Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015 
(8d714a0)
  > x86_64 x86_64 x86_64 GNU/Linux
  >
  > The problem that I am having is that I am running a CAE analysis 
application
  > and during the course of the run, X will 

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Aivils:

The output of the ps aux command gives the following column headers:

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND


Per the ps(1) man page:

VSZ   virtual memory size of the process in KiB
  (1024-byte units).  Device mappings are
  currently excluded; this is subject to change.
  (alias *vsize*).


RSS   resident set size, the non-swapped physical
  memory that a task has used (in kiloBytes).
  (alias *rssize*, *rsz*).


(Source: http://man7.org/linux/man-pages/man1/ps.1.html)

Therefore; as it was previously stated, the size is given in kiB, not B,
which means that the total memory consumed by X is still approximately 100
GiB (104332316 kiB).


Thanks.


Sincerely,


Ewen

On Wed, Dec 6, 2017 at 2:28 AM,  wrote:

> Hi,
> Don't worry. Count the digits. 100Mb consuming is pretty ordinary nowadays.
> They are not Gigabytes.
>
>
> Ewen Chan @ 2017-12-05 20:14 rakstīja:
>
> ewen@aes4:~> date
>> Tue Dec 5 05:08:28 EST 2017
>> ewen@aes4:~> ps aux | grep Xorg
>> root 2245 7.7 79.0 271100160 104332316 tty7 Ssl+ Nov25 1078:19
>> /usr/bin/Xorg :0 -background none -verbose -auth /run/gdm/aut
>> h-for-gdm-9L7Ckz/database -seat seat0 -nolisten tcp vt7
>> ewen 11769 0.0 0.0 10500 944 pts/1 R+ 05:08 0:00 grep --color=auto
>> Xorg
>>
>>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[aivils]

Hi,
Don't worry. Count the digits. 100Mb consuming is pretty ordinary 
nowadays.

They are not Gigabytes.

Ewen Chan @ 2017-12-05 20:14 rakstīja:


ewen@aes4:~> date
Tue Dec 5 05:08:28 EST 2017
ewen@aes4:~> ps aux | grep Xorg
root 2245 7.7 79.0 271100160 104332316 tty7 Ssl+ Nov25 1078:19
/usr/bin/Xorg :0 -background none -verbose -auth /run/gdm/aut
h-for-gdm-9L7Ckz/database -seat seat0 -nolisten tcp vt7
ewen 11769 0.0 0.0 10500 944 pts/1 R+ 05:08 0:00 grep --color=auto
Xorg


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Jose R R]

Niltze [Hello], Ewen-

On Tue, Dec 5, 2017 at 6:53 PM, Ewen Chan  wrote:
> I could try that.
>
> I will have to do quite a bit of research to figure out how though, but ok.
As long as you properly fulfill dependencies, Xorg devs script can
fetch the source and build it for your system.
< https://www.x.org/wiki/Building_the_X_Window_System/#index9h3 >

You must adjust paths to the location of your newly built Xorg binaries.

On the other hand if you have a subscription to SuSE enterprise, they
may provide you with solution(s).

> On Tue, Dec 5, 2017 at 7:36 PM, Hi-Angel  wrote:
>>
>> On 6 December 2017 at 02:36, Vladimir Dergachev 
>> wrote:
>> >
>> > Also, given the the high usage does not happen outside of gnome session,
>> > perhaps this is connected to compositing..
>>
>> There're 2 mails which didn't get yet into the ML because they contain
>> a screenshot, and mailman complained about a suspiciously big size,
>> and sent them to moderation. The TL;DR is that Xorg takes 100GB,
>> however xresttop shows only a few dozens of MBs. Per my understanding
>> this means that Xorg does not hold a memory allocated for some client,
>> but rather have an actual memory leak. So I recommended trying latest
>> Xorg, and reporting a bug if it doesn't help.
>


Best Professional Regards.

-- 
Jose R R
http://metztli.it
-
Download Metztli Reiser4: Debian Stretch w/ Linux 4.14 AMD64
-
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

I'm a little bit confused by your reply here.

If it doesn't rely on GL, can you please help clarify why would I want to
use Xvnc instead?

(Was that suppose to be "If it DOES (rely on GL), to use Xvnc instead"?)

Thanks.

On Tue, Dec 5, 2017 at 7:17 PM, Vladimir Dergachev 
wrote:

>
>
> On Tue, 5 Dec 2017, Ewen Chan wrote:
>
> Not really sure.
>> Someone suggested that I tried Xvfb but I didn't really know how I can
>> use that without using an X server already, and again, in trying to conduct
>> my own due diligence research into the
>> issue, I stumbled upon using ssh -Y and enabling X11 forwarding via ssh
>> so I will have to see how that works next (unless there are other
>> suggestions that come before that that I can also
>> quickly test out as well).
>>
>
> If your app relies on GL you don't want to use ssh -Y.
>
> If it does not, then I recommend running it in Xvnc instead.
>
> best
>
> Vladimir Dergachev
>
>
>
>> Thanks.
>>
>> On Tue, Dec 5, 2017 at 6:36 PM, Vladimir Dergachev <
>> volo...@mindspring.com> wrote:
>>
>>   Also, given the the high usage does not happen outside of gnome
>> session, perhaps this is connected to compositing..
>>
>>   best
>>
>>   Vladimir Dergachev
>>
>>   On Wed, 6 Dec 2017, Hi-Angel wrote:
>>
>> The troubleshooting link you provided states that the high
>> memory
>> usage typically belongs to some other application. Sorry, I
>> am just an
>> occasional bystander here, and can't tell much of technical
>> details,
>> but I imagine it works like this(I hope someone will correct
>> me on
>> details): an app requests, for example, a glx object, and
>> XServer
>> allocates one. When the app is done with the object, it
>> requests
>> XServer to deallocate it. The point is: although this memory
>> accounted
>> on part of XServer process — it is actually owned by the app.
>> The link
>> also states that you can use `xrestop` application to see the
>> owners
>> and amounts of the memory.
>>
>> On 5 December 2017 at 21:14, Ewen Chan 
>> wrote:
>>   To Whom It May Concern:
>>
>>   Hello everybody. My name is Ewen and I am new to this
>> distribution list.
>>
>>   So let me start with a little bit of background and the
>> problem statement of
>>   what I am seeing/encountering.
>>
>>   I am running a SuperMicro Server 6027TR-HTRF
>>   (https://www.supermicro.com/pr
>> oducts/system/2u/6027/sys-6027tr-htrf.cfm)
>>   (which uses a Matrox G200eW graphics chip and it has
>> four half-width nodes,
>>   each node has two processor, each processor is an Intel
>> Xeon E5-2690 (v1)
>>   (8-core, 2.9 GHz stock, HTT disabled) running SuSE
>> Linux Enterprise Server
>>   12 SP1 (SLES 12 SP1).
>>
>>   Here are some of the outputs from the system:
>>
>>   ewen@aes4:~> X -version
>>
>>   X.Org X Server 1.15.2
>>   Release Date: 2014-06-27
>>   X Protocol Version 11, Revision 0
>>   Build Operating System: openSUSE SUSE LINUX
>>   Current Operating System: Linux aes4 3.12.49-11-default
>> #1 SMP Wed Nov 11
>>   20:52:43 UTC 2015 (8d714a0) x86_64
>>   Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.12.
>> 49-11-default
>>   root=UUID=fc4dcdb9-2468-422c-b29f-8da42fd7dec0
>>   resume=/dev/disk/by-uuid/1d5d8
>> a9c-218e-4b66-b094-f5154ab08434 splash=silent
>>   quit showopts crashkernel=123M,high crashkernel=72M,low
>>   Build Date: 12 November 2015  01:23:55AM
>>
>>   Current version of pixman: 0.32.6
>>Before reporting problems, check
>> http://wiki.x.org
>>to make sure that you have the latest version.
>>   ewen@aes4:~> uname -a
>>   Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11
>> 20:52:43 UTC 2015 (8d714a0)
>>   x86_64 x86_64 x86_64 GNU/Linux
>>
>>   The problem that I am having is that I am running a CAE
>> analysis application
>>   and during the course of the run, X will eventually
>> consume close to 100 GiB
>>   of RAM (out of 125 GiB installed)
>>
>>   ewen@aes4:~> date
>>   Tue Dec 5 05:08:28 EST 2017
>>   ewen@aes4:~> ps aux | grep Xorg
>>   root 2245 7.7 79.0 271100160 104332316 tty7 Ssl+ Nov25
>> 1078:19 /usr/bin/Xorg
>>   :0 -background none -verbose -auth /run/gdm/aut
>>   h-for-gdm-9L7Ckz/database -seat seat0 -nolisten tcp vt7
>>   ewen 11769 0.0 0.0 

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

I could try that.

I will have to do quite a bit of research to figure out how though, but ok.

Thank you.

On Tue, Dec 5, 2017 at 7:36 PM, Hi-Angel  wrote:

> On 6 December 2017 at 02:36, Vladimir Dergachev 
> wrote:
> >
> > Also, given the the high usage does not happen outside of gnome session,
> > perhaps this is connected to compositing..
>
> There're 2 mails which didn't get yet into the ML because they contain
> a screenshot, and mailman complained about a suspiciously big size,
> and sent them to moderation. The TL;DR is that Xorg takes 100GB,
> however xresttop shows only a few dozens of MBs. Per my understanding
> this means that Xorg does not hold a memory allocated for some client,
> but rather have an actual memory leak. So I recommended trying latest
> Xorg, and reporting a bug if it doesn't help.
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Hi-Angel]

On 6 December 2017 at 02:36, Vladimir Dergachev  wrote:
>
> Also, given the the high usage does not happen outside of gnome session,
> perhaps this is connected to compositing..

There're 2 mails which didn't get yet into the ML because they contain
a screenshot, and mailman complained about a suspiciously big size,
and sent them to moderation. The TL;DR is that Xorg takes 100GB,
however xresttop shows only a few dozens of MBs. Per my understanding
this means that Xorg does not hold a memory allocated for some client,
but rather have an actual memory leak. So I recommended trying latest
Xorg, and reporting a bug if it doesn't help.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X is consuming ~100 GiB of RAM(!)

[Vladimir Dergachev]

On Tue, 5 Dec 2017, Ewen Chan wrote:


Not really sure.
Someone suggested that I tried Xvfb but I didn't really know how I can use that 
without using an X server already, and again, in trying to conduct my own due 
diligence research into the
issue, I stumbled upon using ssh -Y and enabling X11 forwarding via ssh so I 
will have to see how that works next (unless there are other suggestions that 
come before that that I can also
quickly test out as well).


If your app relies on GL you don't want to use ssh -Y.

If it does not, then I recommend running it in Xvnc instead.

best

Vladimir Dergachev



Thanks.

On Tue, Dec 5, 2017 at 6:36 PM, Vladimir Dergachev  
wrote:

  Also, given the the high usage does not happen outside of gnome session, 
perhaps this is connected to compositing..

  best

  Vladimir Dergachev

  On Wed, 6 Dec 2017, Hi-Angel wrote:

The troubleshooting link you provided states that the high memory
usage typically belongs to some other application. Sorry, I am just 
an
occasional bystander here, and can't tell much of technical details,
but I imagine it works like this(I hope someone will correct me on
details): an app requests, for example, a glx object, and XServer
allocates one. When the app is done with the object, it requests
XServer to deallocate it. The point is: although this memory 
accounted
on part of XServer process — it is actually owned by the app. The 
link
also states that you can use `xrestop` application to see the owners
and amounts of the memory.

On 5 December 2017 at 21:14, Ewen Chan  wrote:
  To Whom It May Concern:

  Hello everybody. My name is Ewen and I am new to this 
distribution list.

  So let me start with a little bit of background and the 
problem statement of
  what I am seeing/encountering.

  I am running a SuperMicro Server 6027TR-HTRF
  
(https://www.supermicro.com/products/system/2u/6027/sys-6027tr-htrf.cfm)
  (which uses a Matrox G200eW graphics chip and it has four 
half-width nodes,
  each node has two processor, each processor is an Intel Xeon 
E5-2690 (v1)
  (8-core, 2.9 GHz stock, HTT disabled) running SuSE Linux 
Enterprise Server
  12 SP1 (SLES 12 SP1).

  Here are some of the outputs from the system:

  ewen@aes4:~> X -version

  X.Org X Server 1.15.2
  Release Date: 2014-06-27
  X Protocol Version 11, Revision 0
  Build Operating System: openSUSE SUSE LINUX
  Current Operating System: Linux aes4 3.12.49-11-default #1 
SMP Wed Nov 11
  20:52:43 UTC 2015 (8d714a0) x86_64
  Kernel command line: 
BOOT_IMAGE=/boot/vmlinuz-3.12.49-11-default
  root=UUID=fc4dcdb9-2468-422c-b29f-8da42fd7dec0
  resume=/dev/disk/by-uuid/1d5d8a9c-218e-4b66-b094-f5154ab08434 
splash=silent
  quit showopts crashkernel=123M,high crashkernel=72M,low
  Build Date: 12 November 2015  01:23:55AM

  Current version of pixman: 0.32.6
           Before reporting problems, check http://wiki.x.org
           to make sure that you have the latest version.
  ewen@aes4:~> uname -a
  Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 
2015 (8d714a0)
  x86_64 x86_64 x86_64 GNU/Linux

  The problem that I am having is that I am running a CAE 
analysis application
  and during the course of the run, X will eventually consume 
close to 100 GiB
  of RAM (out of 125 GiB installed)

  ewen@aes4:~> date
  Tue Dec 5 05:08:28 EST 2017
  ewen@aes4:~> ps aux | grep Xorg
  root 2245 7.7 79.0 271100160 104332316 tty7 Ssl+ Nov25 
1078:19 /usr/bin/Xorg
  :0 -background none -verbose -auth /run/gdm/aut
  h-for-gdm-9L7Ckz/database -seat seat0 -nolisten tcp vt7
  ewen 11769 0.0 0.0 10500 944 pts/1 R+ 05:08 0:00 grep 
--color=auto Xorg

  This does not occur when I perform the same analysis in 
runlevel 3 and when
  I switch back to runlevel 5 and I am using GNOME for the 
desktop
  environment, regardless of whether I initiate the analysis 
via a Terminal
  inside GNOME or I ssh into the system (via cygwin from a 
Windows box), the
  host server's X memory usage will continually increase as the 
analysis
  progresses.

  In trying to research this issue, I have found that I 

Re: X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Not really sure.

Someone suggested that I tried Xvfb but I didn't really know how I can use
that without using an X server already, and again, in trying to conduct my
own due diligence research into the issue, I stumbled upon using ssh -Y and
enabling X11 forwarding via ssh so I will have to see how that works next
(unless there are other suggestions that come before that that I can also
quickly test out as well).

Thanks.

On Tue, Dec 5, 2017 at 6:36 PM, Vladimir Dergachev 
wrote:

>
> Also, given the the high usage does not happen outside of gnome session,
> perhaps this is connected to compositing..
>
> best
>
> Vladimir Dergachev
>
>
> On Wed, 6 Dec 2017, Hi-Angel wrote:
>
> The troubleshooting link you provided states that the high memory
>> usage typically belongs to some other application. Sorry, I am just an
>> occasional bystander here, and can't tell much of technical details,
>> but I imagine it works like this(I hope someone will correct me on
>> details): an app requests, for example, a glx object, and XServer
>> allocates one. When the app is done with the object, it requests
>> XServer to deallocate it. The point is: although this memory accounted
>> on part of XServer process — it is actually owned by the app. The link
>> also states that you can use `xrestop` application to see the owners
>> and amounts of the memory.
>>
>> On 5 December 2017 at 21:14, Ewen Chan  wrote:
>>
>>> To Whom It May Concern:
>>>
>>> Hello everybody. My name is Ewen and I am new to this distribution list.
>>>
>>> So let me start with a little bit of background and the problem
>>> statement of
>>> what I am seeing/encountering.
>>>
>>> I am running a SuperMicro Server 6027TR-HTRF
>>> (https://www.supermicro.com/products/system/2u/6027/sys-6027tr-htrf.cfm)
>>> (which uses a Matrox G200eW graphics chip and it has four half-width
>>> nodes,
>>> each node has two processor, each processor is an Intel Xeon E5-2690 (v1)
>>> (8-core, 2.9 GHz stock, HTT disabled) running SuSE Linux Enterprise
>>> Server
>>> 12 SP1 (SLES 12 SP1).
>>>
>>> Here are some of the outputs from the system:
>>>
>>> ewen@aes4:~> X -version
>>>
>>> X.Org X Server 1.15.2
>>> Release Date: 2014-06-27
>>> X Protocol Version 11, Revision 0
>>> Build Operating System: openSUSE SUSE LINUX
>>> Current Operating System: Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11
>>> 20:52:43 UTC 2015 (8d714a0) x86_64
>>> Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.12.49-11-default
>>> root=UUID=fc4dcdb9-2468-422c-b29f-8da42fd7dec0
>>> resume=/dev/disk/by-uuid/1d5d8a9c-218e-4b66-b094-f5154ab08434
>>> splash=silent
>>> quit showopts crashkernel=123M,high crashkernel=72M,low
>>> Build Date: 12 November 2015  01:23:55AM
>>>
>>> Current version of pixman: 0.32.6
>>>  Before reporting problems, check http://wiki.x.org
>>>  to make sure that you have the latest version.
>>> ewen@aes4:~> uname -a
>>> Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015
>>> (8d714a0)
>>> x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> The problem that I am having is that I am running a CAE analysis
>>> application
>>> and during the course of the run, X will eventually consume close to 100
>>> GiB
>>> of RAM (out of 125 GiB installed)
>>>
>>> ewen@aes4:~> date
>>> Tue Dec 5 05:08:28 EST 2017
>>> ewen@aes4:~> ps aux | grep Xorg
>>> root 2245 7.7 79.0 271100160 104332316 tty7 Ssl+ Nov25 1078:19
>>> /usr/bin/Xorg
>>> :0 -background none -verbose -auth /run/gdm/aut
>>> h-for-gdm-9L7Ckz/database -seat seat0 -nolisten tcp vt7
>>> ewen 11769 0.0 0.0 10500 944 pts/1 R+ 05:08 0:00 grep --color=auto Xorg
>>>
>>> This does not occur when I perform the same analysis in runlevel 3 and
>>> when
>>> I switch back to runlevel 5 and I am using GNOME for the desktop
>>> environment, regardless of whether I initiate the analysis via a Terminal
>>> inside GNOME or I ssh into the system (via cygwin from a Windows box),
>>> the
>>> host server's X memory usage will continually increase as the analysis
>>> progresses.
>>>
>>> In trying to research this issue, I have found that I can either restrict
>>> the amount of cache that X does via ulimit -m (Source:
>>> https://wiki.ubuntu.com/X/Troubleshooting/HighMemory) or I can edit
>>> xorg.conf by adding this option:
>>>
>>> Option "XaaNoPixmapCache"
>>>
>>> (Source: https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.
>>> xhtml)
>>>
>>> Would that be the recommended solution to the problem that I am
>>> experiencing
>>> with X?
>>>
>>> A couple of other notes:
>>>
>>> ewen@aes4:~> free -g
>>>  total   used   free sharedbuffers cached
>>> Mem:   125125  0  0  0  3
>>> -/+ buffers/cache:122  3
>>> Swap:  256170 85
>>> ewen@aes4:~> cat /proc/sys/vm/vfs_cache_pressure
>>> 200
>>>
>>> Your help and commentary would be greatly appreciated. Thank you.
>>>
>>> Sincerely,
>>>
>>> Ewen 

Re: X is consuming ~100 GiB of RAM(!)

[Hi-Angel]

The troubleshooting link you provided states that the high memory
usage typically belongs to some other application. Sorry, I am just an
occasional bystander here, and can't tell much of technical details,
but I imagine it works like this(I hope someone will correct me on
details): an app requests, for example, a glx object, and XServer
allocates one. When the app is done with the object, it requests
XServer to deallocate it. The point is: although this memory accounted
on part of XServer process — it is actually owned by the app. The link
also states that you can use `xrestop` application to see the owners
and amounts of the memory.

On 5 December 2017 at 21:14, Ewen Chan  wrote:
> To Whom It May Concern:
>
> Hello everybody. My name is Ewen and I am new to this distribution list.
>
> So let me start with a little bit of background and the problem statement of
> what I am seeing/encountering.
>
> I am running a SuperMicro Server 6027TR-HTRF
> (https://www.supermicro.com/products/system/2u/6027/sys-6027tr-htrf.cfm)
> (which uses a Matrox G200eW graphics chip and it has four half-width nodes,
> each node has two processor, each processor is an Intel Xeon E5-2690 (v1)
> (8-core, 2.9 GHz stock, HTT disabled) running SuSE Linux Enterprise Server
> 12 SP1 (SLES 12 SP1).
>
> Here are some of the outputs from the system:
>
> ewen@aes4:~> X -version
>
> X.Org X Server 1.15.2
> Release Date: 2014-06-27
> X Protocol Version 11, Revision 0
> Build Operating System: openSUSE SUSE LINUX
> Current Operating System: Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11
> 20:52:43 UTC 2015 (8d714a0) x86_64
> Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.12.49-11-default
> root=UUID=fc4dcdb9-2468-422c-b29f-8da42fd7dec0
> resume=/dev/disk/by-uuid/1d5d8a9c-218e-4b66-b094-f5154ab08434 splash=silent
> quit showopts crashkernel=123M,high crashkernel=72M,low
> Build Date: 12 November 2015  01:23:55AM
>
> Current version of pixman: 0.32.6
>  Before reporting problems, check http://wiki.x.org
>  to make sure that you have the latest version.
> ewen@aes4:~> uname -a
> Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015 (8d714a0)
> x86_64 x86_64 x86_64 GNU/Linux
>
> The problem that I am having is that I am running a CAE analysis application
> and during the course of the run, X will eventually consume close to 100 GiB
> of RAM (out of 125 GiB installed)
>
> ewen@aes4:~> date
> Tue Dec 5 05:08:28 EST 2017
> ewen@aes4:~> ps aux | grep Xorg
> root 2245 7.7 79.0 271100160 104332316 tty7 Ssl+ Nov25 1078:19 /usr/bin/Xorg
> :0 -background none -verbose -auth /run/gdm/aut
> h-for-gdm-9L7Ckz/database -seat seat0 -nolisten tcp vt7
> ewen 11769 0.0 0.0 10500 944 pts/1 R+ 05:08 0:00 grep --color=auto Xorg
>
> This does not occur when I perform the same analysis in runlevel 3 and when
> I switch back to runlevel 5 and I am using GNOME for the desktop
> environment, regardless of whether I initiate the analysis via a Terminal
> inside GNOME or I ssh into the system (via cygwin from a Windows box), the
> host server's X memory usage will continually increase as the analysis
> progresses.
>
> In trying to research this issue, I have found that I can either restrict
> the amount of cache that X does via ulimit -m (Source:
> https://wiki.ubuntu.com/X/Troubleshooting/HighMemory) or I can edit
> xorg.conf by adding this option:
>
> Option "XaaNoPixmapCache"
>
> (Source: https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.xhtml)
>
> Would that be the recommended solution to the problem that I am experiencing
> with X?
>
> A couple of other notes:
>
> ewen@aes4:~> free -g
>  total   used   free sharedbuffers cached
> Mem:   125125  0  0  0  3
> -/+ buffers/cache:122  3
> Swap:  256170 85
> ewen@aes4:~> cat /proc/sys/vm/vfs_cache_pressure
> 200
>
> Your help and commentary would be greatly appreciated. Thank you.
>
> Sincerely,
>
> Ewen Chan
>
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s