Date: Sun, 26 Jul 2020 05:46:55 -0400 From: Aryeh Friedman <aryeh.friedman@gmail.com> To: "Steve O'Hara-Smith" <steve@sohara.org> Cc: Valeri Galtsev <galtsev@kicp.uchicago.edu>, FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: Ask stupid questions and you'll get a stupid answers, was: Technological advantages over Linux Message-ID: <CAGBxaXn5-hQiC56v3u1T8_V339i1WDXu5iq9hq-WUaS%2BsrC_Zw@mail.gmail.com> In-Reply-To: <20200726074655.b0036a0f90508156205376f9@sohara.org> References: <20200214204838.360c8f624397c659946bd764@sohara.org> <20200215063818.GE1482@admin.sibptus.ru> <20200215083359.367d8a3e9ddb4942df67d5b5@sohara.org> <58202623-bbf7-eda0-5cb5-fb4749e91e20@watters.ws> <CAEJNuHxbFSPBB7keSrBufpg=RsgQ8EPK_fvzt8XBROLNKyN_sw@mail.gmail.com> <6318251A-973A-4DEC-9271-12333EB11F7B@kicp.uchicago.edu> <CAEJNuHxC7i%2Bq7cq65=my6mJZDdiK4gpQsKjMU1nvsm=Ri4On%2Bg@mail.gmail.com> <ce61b5e9-b71c-e5b7-c64d-f79884c87435@watters.ws> <20200725152412.GJ92589@admin.sibptus.ru> <CAGBxaX=Ktr-pqtT8FU37ajkYonVLYT_WhSenn23Tj5b=i0d-8g@mail.gmail.com> <20200725162403.GA4721@admin.sibptus.ru> <CAGBxaXmBZcCWqAZFR9OSyRGrqGFU%2BqCAZ8CfOi=0oXAmf-2=tA@mail.gmail.com> <20200725182554.deffc63058a7c9f6d343ef06@sohara.org> <04df312d-9b2b-1873-2117-79a49e089bd9@kicp.uchicago.edu> <CAGBxaX=SR_sm7Pa5KXmTT=P6SCpvuyg9GhVa9WkxdPJM_HUBrg@mail.gmail.com> <20200726074655.b0036a0f90508156205376f9@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 26, 2020 at 2:47 AM Steve O'Hara-Smith <steve@sohara.org> wrote: > On Sat, 25 Jul 2020 22:46:23 -0400 > Aryeh Friedman <aryeh.friedman@gmail.com> wrote: > > > The only thing I can think of is there is a HTML 5 game that I > > often leave open all the time > > That is probably causing Firefox to eat huge amounts of memory > starving everything else and making the system prone to swapping. Try > closing that window, restarting Firefox and then seeing how well your > machine works. > I have already done this experiment and can tell you while it is *PARTIALLY* firefox it is also a fundamental problem with X (and not just the desktop). Experimental lab report: Hypothesis: One or more applications has a resource leak that causes X windows, the app(s) (and all other apps running on the system) to have drastic performance decreases (as measured by response time on non-CPU intensive I/O events) Experiment: Step 1) Reboot machine and start X Step 2) Measure performance Step 3) Start one or more of the offending apps let it run long enough to cause a noticeable performance impact Step 4) Measure performance Step 5) Terminate the offending app(s) via their normal/recommended shutdown method. Step 6) Measure performance Step 7) Repeat steps 3 thru 7 until noticeable loss of performance is noted in step 6 Expected results if there is no system wide performance loss due to the offending apps running: Step 7 should be repeated an undecidable (see CS definition of "undecidable") number of times. If step 7 can only be done 0 time and/or a very small number times (less than 3 times) then we consider this "proof" that the problem is at least partially external to the offending apps. Actual results: While there is a measurable gain in performance in step 6 it does not return to its performance level measured in step 2. Step 7 can only be repeated once before performance becomes unacceptable. Alternative possible explanation: Offending apps and X are not the most current versions from the ports collection. Counter proof to alternative explanation: I update my ports collection at least every 24 hours with the following sequence of commands: cd /usr/ports svn update (read UPDATING if modified) portmaster -ad With the most recent results being: Updated to revision 543457. root@neomarx:/usr/ports # portmaster -ad ===>>> Gathering distinfo list for installed ports ===>>> Starting check of installed ports for available updates ===>>> All ports are up to date and problem has slowly been getting worse Conclusion: While the offending apps (firefox, libreoffice and any multimedia player) do decrease performance stopping and restarting them does not completely solve the problem nor does the problem completely disappear when said apps are not running. This experiment succeeds for all non-X apps and thus we are forced to conclude that at least some of the problem is in X itself in that it never completely deallocates the resources allocated to a given program even after the program terminates. Since the offending apps and GUI config are known to work on Linux without serious performance decay we can only conclude that there is something that causes bad interaction between X and FreeBSD. Repeated attempts at the above experiment over time so the number of times step 7 can be performed are drastically decreasing from essentially undecidable 2 years ago to less then 2 currently and the main difference during this time is the push to make FreeBSD more friendly for X and wayland. > > So the only possible conclusion I can draw > > is it is X being extremely screwy on FreeBSD due to all the linux hacks > in > > it (this despite X's claim it will work on any POSIX machine with the > > right video support). As we move more and more towards wayland as being > > the pixel driver it gets worse. > > However that conclusion isn't supported by the experience of > others, it seems far more likely you have a memory hog, find it and > eliminate it (top is your friend, sorting my resident memory use) and > system performance will improve no end, and yes it may be your desktop > environment, but I'd bet on Firefox which leaks like a seive). > See above. Top clearly shows that X itself is using increasing resources throughout the entire experiment (not just the apps). -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGBxaXn5-hQiC56v3u1T8_V339i1WDXu5iq9hq-WUaS%2BsrC_Zw>