Date: Fri, 12 Nov 2004 12:59:49 +0200 From: Ruslan Ermilov <ru@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: current@freebsd.org Subject: Re: [TEST] make -j patch [take 2] Message-ID: <20041112105949.GG41844@ip.net.ua> In-Reply-To: <94518.1100252100@critter.freebsd.dk> References: <20041112090905.GD41844@ip.net.ua> <94518.1100252100@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--9s922KAXlWjPfK/Q Content-Type: multipart/mixed; boundary="SUk9VBj82R8Xhb8H" Content-Disposition: inline --SUk9VBj82R8Xhb8H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Nov 12, 2004 at 10:35:00AM +0100, Poul-Henning Kamp wrote: > In message <20041112090905.GD41844@ip.net.ua>, Ruslan Ermilov writes: >=20 > >But you don't give an opportunity to control this on a sub-make > >level (that's what I ask for).=20 >=20 > Why would that be of any use ? If you run "make universe" the task > at hand is to get "make universe" to complete. You should not care > which partcular submake starts how many jobs when, you should only > care that it works as efficient as possible. >=20 Please read below. > >level (that's what I ask for). If you implement what I suggest, > >"make -j 12 universe" will still do as you saw it last night, > >while still allowing "make -j4 universe JFLAG=3D3D-j3" to build four > >worlds in parallel, each with three jobs. Isn't it nice? ;) >=20 > You're wrong about how this works. >=20 I LIKE THIS FEATURE BUT IT NEEDS TO BE IMPROVED. :-) > Try plotting your load-avg over time and you will see that you have > neither enforced the 4 nor the 3 jobs. >=20 Of course not. And I didn't say I wanted this. What I want is to build 4 worlds in parallel, each with 3 available jobs, so that the total number of jobs will not exceed 12. > Or look at the one I just posted: >=20 > http://phk.freebsd.dk/misc/make.png >=20 > Then explain to me how you think it is beneficial that "-j 12" > gives make(1) permission to start 65 jobs. >=20 God damn it, I never said I don't like your patch and idea. I like it very much. I just said (and not only me actually) that there should be an option to start afresh, i.e., that a sub-make can ignore the global limit set by its parent, and start on its own. I'm working on a patch now, it's tiny. > When I say "make -j 12" I mean "12 jobs, damnit!", not "up to > 12^(number of levels of subdirectories)". >=20 The global limit is fine. What is not fine, is that it's made global permanently. Now, when you say "make -j 12 buildworld" you won't necessarily be given 12 jobs to build this world, because your parent (e.g., "make universe") may have already eaten some of them, or set this limit to a lower value. And when I say "make -j4 buildworld", I want it to use four jobs for this buildworld, whether it's typed on a command line, or invoked as part of "make universe", still with global limit of four jobs, but only for _this_ buildworld. To picture it down: make -j12 universe should build all worlds using 12 jobs make -j2 universe JFLAG=3D-j6 should build two worlds in parallel, each world using 6 jobs In both cases, the maximum number of makes simultaneously running in the system should not exceed 12. The reason I prefer the latter is that it's more practical to build each world with more jobs available than to build more worlds simultaneously with less jobs available for individual world. If I want to test my change with "make universe", I'm interested in finding if it broke something quickly, right? If it broke one architecture, it's not acceptable for committing. Hence, I want to complete with one world, then switch to another. I'd typically run "make universe JFLAG=3D-jX" when testing, i.e., build worlds sequentially, and only each world in parallel, but YMMV. > The submakes will not respect > an explicit "-j N" argument if they find the environment > variable. You can of course eliminate that if you want to > override this behaviour. >=20 Yeah, that's the ONLY thing I want to be improved, and I will do it. Would you like to see a patch before it gets committed? > >Or perhaps you could explain how your patch helps parallelism > >or improves something, I fail to see it. All I see is that > >it causes N shells to be used instead of one, but this is > >unmeasureable in buildworld times. >=20 > I don't know the reason, but the result was about 5% speedup on > parallel buildworld. >=20 Actually, I see a huge slowdown, and I *know* the reason. With the attached makefile: $ time -h make new 31,90s real 10,24s user 21,28s sys $ time -h make old 0,88s real 0,56s user 0,30s sys $ time -h make -j4 new 8,67s real 7,64s user 0,91s sys $ time -h make -j4 old 0,88s real 0,61s user 0,25s sys Add -l to see the number of context switches. Note how "new" is worse in every case, and note that -jX doesn't really matter for "old". "old" corresponds to the old version of bsd.subdir.mk, and "new" corresponds to your proposed change to bsd.subdir.mk. In the old version, only a single shell is used to print all 10000 numbers, and the shell is passed one line of stdin. In your version, non-parallel make will start 10000 shells to print numbers. With -j4, only a single shell will be used, but make(1) will have to parse 10000 lines, and pass 30000 lines over a pipe to a shell. (You can see it yourself through "make -j4 -dj"). The "4" doesn't really matter, -j1 will give the same time (~8 vs ~31). Sorry, but I just don't trust your 5% speedup claim. ;) > I'll leave it to you if anything needs done, You're the > makefile wizard. >=20 Thanks. > I've done the bit I set out to do: prevent > boundless creation of jobs. >=20 That was much appreciated, thank you! Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --SUk9VBj82R8Xhb8H Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=makefile SUBDIR!= jot 10000 new: .for entry in ${SUBDIR} @echo ${entry} >/dev/null .endfor old: @for entry in ${SUBDIR}; do \ echo $${entry} >/dev/null; \ done --SUk9VBj82R8Xhb8H-- --9s922KAXlWjPfK/Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBlJelqRfpzJluFF4RAvQTAKCIy/mTonV6se2e3tJ6I6lfK+lclQCfb0Lm bl/bPEoZ/VvJSmnuLP+pplw= =SYB2 -----END PGP SIGNATURE----- --9s922KAXlWjPfK/Q--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041112105949.GG41844>