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 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 reminds me of the a
Fwd: X is consuming ~100 GiB of RAM(!)
-- Forwarded message -- From: Hi-Angel Date: 7 December 2017 at 21:12 Subject: Re: X is consuming ~100 GiB of RAM(!) To: Ewen Chan On 7 December 2017 at 19:22, Ewen Chan wrote: >> 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. Problems arise everywhere, it's the state of life per se. Today I been forced to engage with some peoples, also because of them I lost some post. In addition I've been two days arguing with stupid support of wordpress.com who can't understand that their Markdown is broken. But this doesn't make me to claim that all people are bad. The beauty of open source is that when you have a problem, you actually have ways to solve it. After this discussion happened I did even more research, and found that the Matrox driver seems to be in the end FOSS. This means that you actually fix the code, or pay to someone else to fix it. Out of pure luck you don't happen to have the problem on Windows, but now imagine you would. What you gonna do? Let me quote one developer: "What happens when you read some doc and either it doesn't answer your question or is demonstrably wrong? In Linux, you say "Linux sucks" and go read the code. In Windows/Oracle/etc you say "Windows sucks" and start banging your head against the wall." --- Denis Vlasenko on lkml ___ 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(!)
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(!)
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(!)
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 > >> > intel_powerclamp 14690 0 > >> > coretemp 13435 0 > >> > kvm_intel
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 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 >> > libahci36105 1 ahci >> > usbcore
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 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 wrote: > >> > >> Don't worry, I don't believe in Laplac
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 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 >> > Flags: bus master, medium devsel, latency 64, IRQ 11
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 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(!)
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(!)
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 wrote: > >> > >> On 7 December 2017 at 06:19, Hi
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 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
