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

2017-12-05 Thread 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(!)

2017-12-05 Thread 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(!)

2017-12-05 Thread 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(!)

2017-12-05 Thread 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(!)

2017-12-05 Thread 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(!)

2017-12-05 Thread 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(!)

2017-12-05 Thread 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(!)

2017-12-05 Thread 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

X is consuming ~100 GiB of RAM(!)

2017-12-05 Thread Ewen Chan 
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

Re: [RFC PATCH xserver] xwayland: Fix non-argb cursor conversion

2017-12-05 Thread Daniel Stone 
On 27 September 2017 at 17:01, Olivier Fourdan  wrote:
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103012
> Signed-off-by: Olivier Fourdan 

Reviewed-by: Daniel Stone 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 0/2] Move VT check from fb to exa

2017-12-05 Thread Daniel Stone 
Hi,

On 1 December 2017 at 18:14, Adam Jackson  wrote:
> On Fri, 2017-12-01 at 17:00 +, Daniel Stone wrote:
>> Are these OK to push now then?
>
> I had thought that:
>
> commit a49379b6045453c7b787cc638db6afd0d14dce9c
> Author: Adam Jackson 
> Date:   Tue Sep 12 16:53:24 2017 -0400
>
> fb: Check whether the window is enabled directly
>
> was sufficient?

Yeah, it is; I'm just blind.

Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] dix: avoid deferencing NULL PtrCtrl

2017-12-05 Thread Olivier Fourdan 
PtrCtrl really makes sense for relative pointing device only, absolute
devices such as touch devices do not have any PtrCtrl set.

In some cases, if the client issues a XGetPointerControl() immediatlely
after a ChangeMasterDeviceClasses() copied the touch device to the VCP,
a NULL pointer dereference will occur leading to a crash of Xwayland.

Check whether the PtrCtrl is not NULL in ProcGetPointerControl() and
return the default control values oterhwise, to avoid the NULL pointer
dereference.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1519533
Signed-off-by: Olivier Fourdan 
---
 dix/devices.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/dix/devices.c b/dix/devices.c
index ea3c6c8a9..4a628afb0 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -2329,10 +2329,15 @@ int
 ProcGetPointerControl(ClientPtr client)
 {
 DeviceIntPtr ptr = PickPointer(client);
-PtrCtrl *ctrl = >ptrfeed->ctrl;
+PtrCtrl *ctrl;
 xGetPointerControlReply rep;
 int rc;
 
+if (ptr->ptrfeed)
+ctrl = >ptrfeed->ctrl;
+else
+ctrl = 
+
 REQUEST_SIZE_MATCH(xReq);
 
 rc = XaceHook(XACE_DEVICE_ACCESS, client, ptr, DixGetAttrAccess);
-- 
2.14.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel