Re: Periodic rant about SCHED_ULE
- Reply: Mark Millard : "Re: Periodic rant about SCHED_ULE"
- In reply to: George Mitchell : "Re: Periodic rant about SCHED_ULE"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 22 Mar 2023 20:34:17 UTC
On Mar 22, 2023, at 12:40, George Mitchell <george+freebsd@m5p.com> wrote: > On 3/22/23 15:21, Mark Millard wrote: >> George Mitchell <george+freebsd@m5p.com> wrote on >> Date: Wed, 22 Mar 2023 17:36:39 UTC : >> [...] >>> Here are the very complicated instructions for reproducing the problem: >>> 1. Install and start misc/dnetc from ports. >> Installing is likely easy, as likely would be building >> with default options (if any). I know nothing about >> starting misc/dnetc so that is research. (Possibly >> trivial, although if it has alternatives to control >> then I'd need to match that context too.) > > service dnetc start I built and installed misc/dnetc and got a binary blob that clearly was not built in my environment: # file /usr/local/distributed.net/dnetc /usr/local/distributed.net/dnetc: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 10.1 (1001515), FreeBSD-style, stripped Way older FreeBSD vintage than the locally available toolchains would normally build. Some might be cautious about such a thing. The man page reported that: QUOTE If you have never run the client before, it will initiate the menu-driven configuration. Save and quit when done, the configuration file will be saved in the same directory as the client. Now, simply restart the client. From that point on it will use the saved configuration. END QUOTE I've not seen what the configuration asks about yet. >>> 2. Run "make buildworld". >> So on the 32 hardware-thread (16 cores) amd64 machine that >> I have access to, the test is to only have buildworld use >> about one hardware thread, no matter what else is going on. >> I never would have guessed that the steps would not involve >> more like -j$(sysctl -n hw.ncpu) (so around -j32 in this >> context). So it is good that you provided your note or >> I'd not know if I'd done similarly or not when trying such. >> [Note: -j1 and lack of -j are not strictly equivalent in >> how make operates. As I remember, the distinction makes >> a notable difference in the number of subprocesses created >> directly by make (one per action "line" vs. one for the >> whole block?). So even using -j1 might make a difference >> vs. what you specified. I'd have to test to see.] > > I am literally running "make buildworld" with no additional options. So required for repeating your results, but likely making such results not be interesting relative to how I normally deal with buildworld buildkernel and the likel, no matter if there is other activity in an overlapping time frame or not: my time preferences are too strong to wait for a single hardware thread to do my normal builds, even with no competing activity on the builder. >>> Standard out conveniently reports how long it took (wall clock). >> But nothing in your instructions indicate about how >> to get an idea much progress dnetc made during the >> various tests? [...] > > Honestly, I've never worried about this part. But dnetc logs its > progress in /usr/local/distributed.net/dnetc.txt, though not in terms > that are easy to relate to real-world progress. Oddly, when I run > "make buildworld," I'm primarily interested in getting the world built. > Perhaps others feel differently. Off topic for the specifics of the actual benchmark that you run: Then why not use of -jN ? In my context, any buildworld using -j1 or no -j at all takes a huge amount of time longer than letting it use all the hardware threads (or so). (I've avoided having any I/O bound contexts for such.) It does not take additional load on the system for that to be true --including on the 4-core small arm boards when I happen to buildworld on such (rare). >> [...] >> FYI: I've never built with and run the alternate >> scheduler so if there is any appropriate background >> for that that would not be obvious on finding basic >> instructions, it would be appropriate to provide >> such notes. >> [...] > > You have to build a new kernel, using a config file in which you have > replaced "options SCHED_ULE" with "options SCHED_4BSD". -- George Thanks for the notes. I've not decided if I'll do anything with the binary blob or not. === Mark Millard marklmi at yahoo.com