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