<div dir="ltr">Hi-Angel:<div><br></div><div>> <span style="font-size:12.8px">Yes, now it should be using CPU for rendering.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Hmmm...I am not so sure if that was really what I want.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">That's one more of </span><span style="font-size:12.8px">beauties of open source</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">People keep talking about great and wonderful Linux is, but this experience has been anything but.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Pros (for Linux): It's faster when it is running at runlevel 3.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Such a pity really that this has the potential to be *<b>A*</b>, if not *<b>THE*</b> solution to this problem.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Hmmm....it's been interesting.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I can still try other stuff (like iomem=relaxed), both either with the mgag200 or without it.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thanks.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Sincerely,</span></div><div><span style="font-size:12.8px">Ewen</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 7, 2017 at 11:04 AM, Hi-Angel <span dir="ltr"><<a href="mailto:hiangel999@gmail.com" target="_blank">hiangel999@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, now it should be using CPU for rendering. If you're eager to save<br>
some cycles, you could recompile both Xorg and Mesa with optimizations<br>
"-flto=2 -march=native -O3 -pipe -fno-stack-protector<br>
-fno-semantic-interposition -fmerge-all-constants". That's one more of<br>
beauties of open source :) That said, I don't know how hard it might<br>
be on SuSe. On Archlinux here we have ᴬᵁᴿ repository, and building<br>
e.g. mesa from source is as easy as a command "yaourt -S mesa-git".<br>
<div class="HOEnZb"><div class="h5"><br>
On 7 December 2017 at 18:36, Ewen Chan <<a href="mailto:chan.ewen@gmail.com">chan.ewen@gmail.com</a>> wrote:<br>
> Hi-Angel:<br>
><br>
> I'm just asking due to innate curiosity.<br>
><br>
> But the other part of it is I am wondering if the other driver is using CPU<br>
> cycles to draw/render the display/(raster?).<br>
><br>
> I am asking because in the analyis runs, they are taking longer to run than<br>
> they were before I blacklisted the mgag200 driver. (Granted it is still very<br>
> early in the entire script, but the early results would suggest that the<br>
> system might now be using the CPU to draw/render the screen (raster?) due to<br>
> the analysis runs now taking longer to complete (for each of the three out<br>
> of 16 runs that I have completed so far).<br>
><br>
> Thanks.<br>
><br>
> Sincerely,<br>
> Ewen<br>
><br>
> On Thu, Dec 7, 2017 at 10:32 AM, Hi-Angel <<a href="mailto:hiangel999@gmail.com">hiangel999@gmail.com</a>> wrote:<br>
>><br>
>> Yeah, nice, it worked. As for what other driver in the output should<br>
>> accord to vesa or whatever that provides the basic functional of<br>
>> outputting to a monitor — sorry, I don't know, I hope somebody else<br>
>> here can tell it. I don't think it's important for our purposes<br>
>> though.<br>
>><br>
>> On 7 December 2017 at 18:18, Ewen Chan <<a href="mailto:chan.ewen@gmail.com">chan.ewen@gmail.com</a>> wrote:<br>
>> > Hi-Angel:<br>
>> ><br>
>> >> Have you rebuild initramfs after blacklisting by the way?<br>
>> ><br>
>> > So...I did what that thread (and the thread that it points to within<br>
>> > that<br>
>> > thread) says to do.<br>
>> ><br>
>> > Created blacklist.conf and then put in there:<br>
>> ><br>
>> > blacklist mgag200<br>
>> ><br>
>> > and then I ran dracut --regenerate-all --force and rebooted (per the<br>
>> > thread-inside-that-thread's instructions).<br>
>> ><br>
>> > (like I said, I'm a grossly underqualified sysadmin so I just do what "I<br>
>> > am<br>
>> > told" from those sources.)<br>
>> ><br>
>> ><br>
>> > Here is the output of lsmod:<br>
>> ><br>
>> > Module                  Size  Used by<br>
>> > ebtable_filter         12827  0<br>
>> > ebtables               35009  1 ebtable_filter<br>
>> > ip6table_filter        12815  0<br>
>> > ip6_tables             27025  1 ip6table_filter<br>
>> > iptable_filter         12810  0<br>
>> > ip_tables              27239  1 iptable_filter<br>
>> > x_tables               34059  5<br>
>> > ip6table_filter,ip_tables,<wbr>iptable_filter,ebtables,ip6_<wbr>tables<br>
>> > af_packet              39847  0<br>
>> > fuse                   95758  3<br>
>> > iscsi_ibft             12862  0<br>
>> > iscsi_boot_sysfs       16051  1 iscsi_ibft<br>
>> > raw                    13091  0<br>
>> > msr                    12865  0<br>
>> > joydev                 17344  0<br>
>> > iTCO_wdt               13480  0<br>
>> > iTCO_vendor_support    13718  1 iTCO_wdt<br>
>> > dm_mod                110780  0<br>
>> > intel_rapl             18783  0<br>
>> > intel_powerclamp       14690  0<br>
>> > coretemp               13435  0<br>
>> > kvm_intel             151399  0<br>
>> > kvm                   496652  1 kvm_intel<br>
>> > crct10dif_pclmul       14307  0<br>
>> > crc32_pclmul           13133  0<br>
>> > crc32c_intel           22094  0<br>
>> > pcspkr                 12718  0<br>
>> > sb_edac                26894  0<br>
>> > edac_core              66438  1 sb_edac<br>
>> > igb                   204492  0<br>
>> > ptp                    18933  1 igb<br>
>> > i2c_i801               22557  0<br>
>> > pps_core               19333  1 ptp<br>
>> > ipmi_si                57482  0<br>
>> > i2c_algo_bit           13413  1 igb<br>
>> > ipmi_msghandler        49676  1 ipmi_si<br>
>> > mei_me                 18355  0<br>
>> > wmi                    19193  0<br>
>> > mei                    86782  1 mei_me<br>
>> > lpc_ich                21093  0<br>
>> > ioatdma                71777  0<br>
>> > mfd_core               13435  1 lpc_ich<br>
>> > shpchp                 32951  0<br>
>> > dca                    15130  2 igb,ioatdma<br>
>> > processor              44678  0<br>
>> > button                 13971  0<br>
>> > hid_generic            12559  0<br>
>> > usbhid                 52573  0<br>
>> > btrfs                1022893  2<br>
>> > xor                    21411  1 btrfs<br>
>> > raid6_pq              101908  1 btrfs<br>
>> > sd_mod                 50160  4<br>
>> > ghash_clmulni_intel    13230  0<br>
>> > aesni_intel            52860  0<br>
>> > isci                  149868  0<br>
>> > aes_x86_64             17131  1 aesni_intel<br>
>> > glue_helper            13990  1 aesni_intel<br>
>> > lrw                    13286  1 aesni_intel<br>
>> > gf128mul               14951  1 lrw<br>
>> > ablk_helper            13597  1 aesni_intel<br>
>> > cryptd                 16263  3<br>
>> > ghash_clmulni_intel,aesni_<wbr>intel,ablk_helper<br>
>> > ehci_pci               12914  0<br>
>> > libsas                 87336  1 isci<br>
>> > ehci_hcd               79237  1 ehci_pci<br>
>> > ahci                   29929  2<br>
>> > scsi_transport_sas     45130  2 isci,libsas<br>
>> > libahci                36105  1 ahci<br>
>> > usbcore               254961  3 ehci_hcd,ehci_pci,usbhid<br>
>> > libata                244519  3 ahci,libahci,libsas<br>
>> > usb_common             13057  1 usbcore<br>
>> > sg                     40629  0<br>
>> > scsi_mod              244588  6<br>
>> > sg,isci,scsi_transport_sas,<wbr>libata,libsas,sd_mod<br>
>> > autofs4                42930  2<br>
>> ><br>
>> > Out of that list, I don't see mgag200 there, but then again, I also<br>
>> > don't<br>
>> > see any module that I recognize as being a "video driver" either.<br>
>> ><br>
>> > I hope that helps answer your questions(? 0.o?)<br>
>> ><br>
>> > Thanks.<br>
>> ><br>
>> > Sincerely,<br>
>> > Ewen<br>
>> ><br>
>> ><br>
>> > On Thu, Dec 7, 2017 at 1:46 AM, Hi-Angel <<a href="mailto:hiangel999@gmail.com">hiangel999@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Don't worry, I don't believe in Laplace's demon, and hence I believe<br>
>> >> everybody don't know something.<br>
>> >><br>
>> >> Tbh I'm not sure if the output of lspci implies the module is still<br>
>> >> loaded, although I would assume it still is. Either way, to be sure<br>
>> >> you can use `lsmod` command, it lists all currently loaded modules.<br>
>> >> Have you rebuild initramfs after blacklisting by the way?<br>
>> >><br>
>> >> On 7 December 2017 at 08:32, Ewen Chan <<a href="mailto:chan.ewen@gmail.com">chan.ewen@gmail.com</a>> wrote:<br>
>> >> > Stupid question though (again, I'm a grossly underqualified<br>
>> >> > sysadmin).<br>
>> >> ><br>
>> >> > How can I tell if the blacklisting worked correctly?<br>
>> >> ><br>
>> >> > When I type in:<br>
>> >> ><br>
>> >> > # lspci -v | more<br>
>> >> ><br>
>> >> > this is what it outputs for the VGA section:<br>
>> >> ><br>
>> >> > 08:01.0 VGA compatible controller: Matrox Electronics Systems Ltd.<br>
>> >> > MGA<br>
>> >> > G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])<br>
>> >> >         Subsystem: Super Micro Computer Inc Device 062f<br>
>> >> >         Flags: bus master, medium devsel, latency 64, IRQ 11<br>
>> >> >         Memory at dd000000 (32-bit, prefetchable) [size=16M]<br>
>> >> >         Memory at df800000 (32-bit, non-prefetchable) [size=16K]<br>
>> >> >         Memory at df000000 (32-bit, non-prefetchable) [size=8M]<br>
>> >> >         Expansion ROM at <unassigned> [disabled]<br>
>> >> >         Capabilities: [dc] Power Management version 1<br>
>> >> >         Kernel modules: mgag200<br>
>> >> ><br>
>> >> > Is there another way to confirm that the blacklisting did what it was<br>
>> >> > supposed to?<br>
>> >> ><br>
>> >> > Thanks.<br>
>> >> ><br>
>> >> > On Wed, Dec 6, 2017 at 11:39 PM, Hi-Angel <<a href="mailto:hiangel999@gmail.com">hiangel999@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> On 7 December 2017 at 06:19, Hi-Angel <<a href="mailto:hiangel999@gmail.com">hiangel999@gmail.com</a>> wrote:<br>
>> >> >> > On 7 December 2017 at 06:05, Ewen Chan <<a href="mailto:chan.ewen@gmail.com">chan.ewen@gmail.com</a>><br>
>> >> >> > wrote:<br>
>> >> >> >> Hi-Angel:<br>
>> >> >> >><br>
>> >> >> >> Thank you for that!!!<br>
>> >> >> >><br>
>> >> >> >> Two questions:<br>
>> >> >> >><br>
>> >> >> >> 1) Will the commands from the CentOS distro work with SuSE?<br>
>> >> >> ><br>
>> >> >> > Well, the linked post doesn't show how to blacklist because it was<br>
>> >> >> > created after the fact (author forgot to re-build initramfs). For<br>
>> >> >> > an<br>
>> >> >> > example of doing that you can refer e.g. this<br>
>> >> >> > <a href="https://askubuntu.com/a/110343/266507" rel="noreferrer" target="_blank">https://askubuntu.com/a/<wbr>110343/266507</a> Except I am not sure how to<br>
>> >> >> > rebuild initramfs on SuSe — on Archlinux I'm using it is `sudo<br>
>> >> >> > mkinitcpio -p linux`.<br>
>> >> >> ><br>
>> >> >> >> 2) Do you think there will be problems using the VESA driver<br>
>> >> >> >> instead<br>
>> >> >> >> of<br>
>> >> >> >> the<br>
>> >> >> >> mgag200 driver? (i.e. the GUI/remote X/VNC would exhibit<br>
>> >> >> >> unexpected<br>
>> >> >> >> behaviours?<br>
>> >> >> ><br>
>> >> >> > Nothing that I know of. You'd obviously get a lower graphics<br>
>> >> >> > performance, but otherwise I think it should be fine.<br>
>> >> >><br>
>> >> >> You know, btw, another silly idea: if blacklisting the driver will<br>
>> >> >> help, but you actually care of graphics performance — you could try<br>
>> >> >> enabling it back, and then installing modesetting driver, and<br>
>> >> >> forcing<br>
>> >> >> Xorg to use it through a xorg.conf. Per my understanding the leak<br>
>> >> >> could specifically be in Matrox DDX driver — if this is the case, by<br>
>> >> >> replacing it with modesetting DDX you'd keep the performance and get<br>
>> >> >> rid of leaks. "modesetting" is a vendor-neutral DDX driver which is<br>
>> >> >> implemented on top of whatever driver provides OpenGL functional.<br>
>> >> >><br>
>> >> >> It should be noted though that if leaks are in the matrox's<br>
>> >> >> provision<br>
>> >> >> of OpenGL, it won't help.<br>
>> >> ><br>
>> >> ><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>