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

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,

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: X is consuming ~100 GiB of RAM(!)

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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