X is consuming ~100 GiB of RAM(!)

Hi-Angel hiangel999 at gmail.com
Thu Dec 7 16:04:15 UTC 2017


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 <chan.ewen at gmail.com> 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 <hiangel999 at gmail.com> 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 <chan.ewen at gmail.com> 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_filter        12815  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
>> > raw                    13091  0
>> > msr                    12865  0
>> > joydev                 17344  0
>> > iTCO_wdt               13480  0
>> > iTCO_vendor_support    13718  1 iTCO_wdt
>> > dm_mod                110780  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_edac                26894  0
>> > edac_core              66438  1 sb_edac
>> > igb                   204492  0
>> > ptp                    18933  1 igb
>> > i2c_i801               22557  0
>> > pps_core               19333  1 ptp
>> > ipmi_si                57482  0
>> > i2c_algo_bit           13413  1 igb
>> > ipmi_msghandler        49676  1 ipmi_si
>> > mei_me                 18355  0
>> > wmi                    19193  0
>> > mei                    86782  1 mei_me
>> > lpc_ich                21093  0
>> > ioatdma                71777  0
>> > mfd_core               13435  1 lpc_ich
>> > shpchp                 32951  0
>> > dca                    15130  2 igb,ioatdma
>> > processor              44678  0
>> > button                 13971  0
>> > hid_generic            12559  0
>> > usbhid                 52573  0
>> > btrfs                1022893  2
>> > xor                    21411  1 btrfs
>> > raid6_pq              101908  1 btrfs
>> > sd_mod                 50160  4
>> > ghash_clmulni_intel    13230  0
>> > aesni_intel            52860  0
>> > isci                  149868  0
>> > aes_x86_64             17131  1 aesni_intel
>> > glue_helper            13990  1 aesni_intel
>> > lrw                    13286  1 aesni_intel
>> > gf128mul               14951  1 lrw
>> > ablk_helper            13597  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
>> > libahci                36105  1 ahci
>> > usbcore               254961  3 ehci_hcd,ehci_pci,usbhid
>> > libata                244519  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
>> > autofs4                42930  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 <hiangel999 at gmail.com> 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 <chan.ewen at gmail.com> 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 dd000000 (32-bit, prefetchable) [size=16M]
>> >> >         Memory at df800000 (32-bit, non-prefetchable) [size=16K]
>> >> >         Memory at df000000 (32-bit, non-prefetchable) [size=8M]
>> >> >         Expansion ROM at <unassigned> [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 <hiangel999 at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On 7 December 2017 at 06:19, Hi-Angel <hiangel999 at gmail.com> wrote:
>> >> >> > On 7 December 2017 at 06:05, Ewen Chan <chan.ewen at gmail.com>
>> >> >> > 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.
>> >> >
>> >> >
>> >
>> >
>
>


More information about the xorg mailing list