Date: Sun, 26 Jul 2020 13:43:31 +0100 From: Steve O'Hara-Smith <steve@sohara.org> To: freebsd-questions@freebsd.org Subject: Re: Ask stupid questions and you'll get a stupid answers, was: Technological advantages over Linux Message-ID: <20200726134331.5c960f7f93d76d2249bd769c@sohara.org> In-Reply-To: <CAGBxaXn5-hQiC56v3u1T8_V339i1WDXu5iq9hq-WUaS%2BsrC_Zw@mail.gmail.com> 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> <CAGBxaXn5-hQiC56v3u1T8_V339i1WDXu5iq9hq-WUaS%2BsrC_Zw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 26 Jul 2020 05:46:55 -0400 Aryeh Friedman <aryeh.friedman@gmail.com> wrote: > On Sun, Jul 26, 2020 at 2:47 AM Steve O'Hara-Smith <steve@sohara.org> > wrote: > > 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: If it were a fundamental problem with X then we would all be suffering it. I can run X for months on end without trouble or leaks other than Firefox. > 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) Anything that eats memory uncontrollably will do that, with or without X. > 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 That sounds like swap recovery to me. > 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 There is system wide performance loss due to pages having been pushed out to swap and needing to be pulled in to be used. The more times you push the memory over the edge like that the more random things get pushed out to swap and the more random delays there will be as they get pulled back in. This happens because some of the stuff that got pushed to swap the first time round never comes back in (it isn't used often enough) and so every time round more and more important stuff gets pushed out to swap. Here is a variant of your experiment that should demonstrate it. 1: Reboot machine, measure performance 2: Memory stress machine to until swapping reduces performance 3: Kill memory stressing process 4: Disable swap - which forces all pages back into RAM 5: Enable swap 6: Loop to 2 I think you'll find that will behave consistently until the hardware fails. -- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200726134331.5c960f7f93d76d2249bd769c>