{"thread":{"id":"49471","subject":"[PATCH v3] coccicheck: process every source file at once","startedAt":"2018-10-02T20:07:49Z","lastAt":"2018-10-10T13:59:56Z","messageCount":20,"participants":["Jacob Keller","SZEDER Gábor","Jeff King","Keller, Jacob E","René Scharfe","Beat Bolli"],"isPatch":true,"patchVersion":3,"patchTotal":null},"messages":[{"id":"359460","messageId":"20181002200710.15721-1-jacob.e.keller@intel.com","threadId":"49471","inReplyTo":null,"subject":"[PATCH v3] coccicheck: process every source file at once","fromName":"Jacob Keller","fromEmail":"jacob.e.keller@intel.com","sentAt":"2018-10-02T20:07:10Z","receivedAt":"2018-10-02T20:07:49Z","isPatch":true,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"From: Jacob Keller \n\nmake coccicheck is used in order to apply coccinelle semantic patches,\nand see if any of the transformations found within contrib/coccinelle/\ncan be applied to the current code base.\n\nPass every file to a single invocation of spatch, instead of running\nspatch once per source file.\n\nThis reduces the time required to run make coccicheck by a significant\namount of time:\n\nPrior timing of make coccicheck\n real 6m14.090s\n user 25m2.606s\n sys 1m22.919s\n\nNew timing of make coccicheck\n real 1m36.580s\n user 7m55.933s\n sys 0m18.219s\n\nThis is nearly a 4x decrease in the time required to run make\ncoccicheck. This is due to the overhead of restarting spatch for every\nfile. By processing all files at once, we can amortize this startup cost\nacross the total number of files, rather than paying it once per file.\n\nSigned-off-by: Jacob Keller \n---\n Makefile | 6 ++----\n 1 file changed, 2 insertions(+), 4 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex df1df9db78da..da692ece9e12 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -2715,10 +2715,8 @@ endif\n %.cocci.patch: %.cocci $(COCCI_SOURCES)\n \t@echo ' ' SPATCH $<; \\\n \tret=0; \\\n-\tfor f in $(COCCI_SOURCES); do \\\n-\t\t$(SPATCH) --sp-file $< $$f $(SPATCH_FLAGS) || \\\n-\t\t\t{ ret=$$?; break; }; \\\n-\tdone >$@+ 2>$@.log; \\\n+\t$(SPATCH) --sp-file $< $(COCCI_SOURCES) $(SPATCH_FLAGS) >$@+ 2>$@.log; \\\n+\tret=$$?; \\\n \tif test $$ret != 0; \\\n \tthen \\\n \t\tcat $@.log; \\\n-- \n2.18.0.219.gaf81d287a9da\n\n"},{"id":"359461","messageId":"CA+P7+xoqKG84n5EMKbajuZoXrOKZMudZ6CT-OKzz8XYyTYaCWQ@mail.gmail.com","threadId":"49471","inReplyTo":"20181002200710.15721-1-jacob.e.keller@intel.com","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2018-10-02T20:18:14Z","receivedAt":"2018-10-02T20:18:29Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Oct 2, 2018 at 1:07 PM Jacob Keller wrote:\n>\n> From: Jacob Keller \n>\n> make coccicheck is used in order to apply coccinelle semantic patches,\n> and see if any of the transformations found within contrib/coccinelle/\n> can be applied to the current code base.\n>\n> Pass every file to a single invocation of spatch, instead of running\n> spatch once per source file.\n>\n> This reduces the time required to run make coccicheck by a significant\n> amount of time:\n>\n> Prior timing of make coccicheck\n> real 6m14.090s\n> user 25m2.606s\n> sys 1m22.919s\n>\n> New timing of make coccicheck\n> real 1m36.580s\n> user 7m55.933s\n> sys 0m18.219s\n>\n> This is nearly a 4x decrease in the time required to run make\n> coccicheck. This is due to the overhead of restarting spatch for every\n> file. By processing all files at once, we can amortize this startup cost\n> across the total number of files, rather than paying it once per file.\n>\n> Signed-off-by: Jacob Keller \n> ---\n\nForgot to add what changed. I dropped the subshell and \"||\" bit around\ninvoking spatch.\n\nThanks,\nJake\n\n\n> Makefile | 6 ++----\n> 1 file changed, 2 insertions(+), 4 deletions(-)\n>\n> diff --git a/Makefile b/Makefile\n> index df1df9db78da..da692ece9e12 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -2715,10 +2715,8 @@ endif\n> %.cocci.patch: %.cocci $(COCCI_SOURCES)\n> @echo ' ' SPATCH $<; \\\n> ret=0; \\\n> - for f in $(COCCI_SOURCES); do \\\n> - $(SPATCH) --sp-file $< $$f $(SPATCH_FLAGS) || \\\n> - { ret=$$?; break; }; \\\n> - done >$@+ 2>$@.log; \\\n> + $(SPATCH) --sp-file $< $(COCCI_SOURCES) $(SPATCH_FLAGS) >$@+ 2>$@.log; \\\n> + ret=$$?; \\\n> if test $$ret != 0; \\\n> then \\\n> cat $@.log; \\\n> --\n> 2.18.0.219.gaf81d287a9da\n>\n"},{"id":"359650","messageId":"CA+P7+xo=cY2nSHk99CETvba-nZ_jOan5YgpDUjaD=cpTs2ub3A@mail.gmail.com","threadId":"49471","inReplyTo":"CA+P7+xoqKG84n5EMKbajuZoXrOKZMudZ6CT-OKzz8XYyTYaCWQ@mail.gmail.com","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2018-10-05T02:17:47Z","receivedAt":"2018-10-05T02:18:02Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Oct 2, 2018 at 1:18 PM Jacob Keller wrote:\n>\n> On Tue, Oct 2, 2018 at 1:07 PM Jacob Keller wrote:\n> >\n> > From: Jacob Keller \n> >\n> > make coccicheck is used in order to apply coccinelle semantic patches,\n> > and see if any of the transformations found within contrib/coccinelle/\n> > can be applied to the current code base.\n> >\n> > Pass every file to a single invocation of spatch, instead of running\n> > spatch once per source file.\n> >\n> > This reduces the time required to run make coccicheck by a significant\n> > amount of time:\n> >\n> > Prior timing of make coccicheck\n> > real 6m14.090s\n> > user 25m2.606s\n> > sys 1m22.919s\n> >\n> > New timing of make coccicheck\n> > real 1m36.580s\n> > user 7m55.933s\n> > sys 0m18.219s\n> >\n> > This is nearly a 4x decrease in the time required to run make\n> > coccicheck. This is due to the overhead of restarting spatch for every\n> > file. By processing all files at once, we can amortize this startup cost\n> > across the total number of files, rather than paying it once per file.\n> >\n> > Signed-off-by: Jacob Keller \n> > ---\n>\n> Forgot to add what changed. I dropped the subshell and \"||\" bit around\n> invoking spatch.\n>\n> Thanks,\n> Jake\n>\n\nJunio, do you want me to update the commit message on my side with the\nmemory concerns? Or could you update it to mention memory as a noted\ntrade off.\n\nThanks,\nJake\n\n>\n> > Makefile | 6 ++----\n> > 1 file changed, 2 insertions(+), 4 deletions(-)\n> >\n> > diff --git a/Makefile b/Makefile\n> > index df1df9db78da..da692ece9e12 100644\n> > --- a/Makefile\n> > +++ b/Makefile\n> > @@ -2715,10 +2715,8 @@ endif\n> > %.cocci.patch: %.cocci $(COCCI_SOURCES)\n> > @echo ' ' SPATCH $<; \\\n> > ret=0; \\\n> > - for f in $(COCCI_SOURCES); do \\\n> > - $(SPATCH) --sp-file $< $$f $(SPATCH_FLAGS) || \\\n> > - { ret=$$?; break; }; \\\n> > - done >$@+ 2>$@.log; \\\n> > + $(SPATCH) --sp-file $< $(COCCI_SOURCES) $(SPATCH_FLAGS) >$@+ 2>$@.log; \\\n> > + ret=$$?; \\\n> > if test $$ret != 0; \\\n> > then \\\n> > cat $@.log; \\\n> > --\n> > 2.18.0.219.gaf81d287a9da\n> >\n"},{"id":"359670","messageId":"20181005124048.GT23446@localhost","threadId":"49471","inReplyTo":"CA+P7+xo=cY2nSHk99CETvba-nZ_jOan5YgpDUjaD=cpTs2ub3A@mail.gmail.com","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-10-05T12:40:48Z","receivedAt":"2018-10-05T12:40:55Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Oct 04, 2018 at 07:17:47PM -0700, Jacob Keller wrote:\n> Junio, do you want me to update the commit message on my side with the\n> memory concerns? Or could you update it to mention memory as a noted\n> trade off.\n\nWe have been running 'make -j2 coccicheck' in the static analysis\nbuild job on Travis CI, which worked just fine so far. The Travis CI\nbuild environments have 3GB of memory available [1], but, as shown in\n[2], with this patch the memory consumption jumps up to about\n1.3-1.8GB for each of those jobs. So with two parallel jobs we will\nvery likely bump into this limit.\n\nSo this patch should definitely change that build script to run only a\nsingle job.\n\n\n1 - https://docs.travis-ci.com/user/common-build-problems/#my-build-script-is-killed-without-any-error\n2 - https://public-inbox.org/git/20181003101658.GM23446@localhost/\n\n\n> > > Makefile | 6 ++----\n> > > 1 file changed, 2 insertions(+), 4 deletions(-)\n> > >\n> > > diff --git a/Makefile b/Makefile\n> > > index df1df9db78da..da692ece9e12 100644\n> > > --- a/Makefile\n> > > +++ b/Makefile\n> > > @@ -2715,10 +2715,8 @@ endif\n> > > %.cocci.patch: %.cocci $(COCCI_SOURCES)\n> > > @echo ' ' SPATCH $<; \\\n> > > ret=0; \\\n> > > - for f in $(COCCI_SOURCES); do \\\n> > > - $(SPATCH) --sp-file $< $$f $(SPATCH_FLAGS) || \\\n> > > - { ret=$$?; break; }; \\\n> > > - done >$@+ 2>$@.log; \\\n> > > + $(SPATCH) --sp-file $< $(COCCI_SOURCES) $(SPATCH_FLAGS) >$@+ 2>$@.log; \\\n> > > + ret=$$?; \\\n> > > if test $$ret != 0; \\\n> > > then \\\n> > > cat $@.log; \\\n> > > --\n> > > 2.18.0.219.gaf81d287a9da\n> > >\n"},{"id":"359696","messageId":"20181005162517.GB11254@sigill.intra.peff.net","threadId":"49471","inReplyTo":"20181005124048.GT23446@localhost","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-05T16:25:17Z","receivedAt":"2018-10-05T16:25:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 05, 2018 at 02:40:48PM +0200, SZEDER Gábor wrote:\n\n> On Thu, Oct 04, 2018 at 07:17:47PM -0700, Jacob Keller wrote:\n> > Junio, do you want me to update the commit message on my side with the\n> > memory concerns? Or could you update it to mention memory as a noted\n> > trade off.\n> \n> We have been running 'make -j2 coccicheck' in the static analysis\n> build job on Travis CI, which worked just fine so far. The Travis CI\n> build environments have 3GB of memory available [1], but, as shown in\n> [2], with this patch the memory consumption jumps up to about\n> 1.3-1.8GB for each of those jobs. So with two parallel jobs we will\n> very likely bump into this limit.\n> \n> So this patch should definitely change that build script to run only a\n> single job.\n\nIt should still be a net win, since the total CPU seems to drop by a\nfactor of 3-4.\n\nAre we OK with saying 1.3-1.8GB is necessary to run coccicheck? That\ndoesn't feel like an exorbitant request for a developer-only tool these\ndays, but I have noticed some people on the list tend to have lousier\nmachines than I do. ;)\n\n-Peff\n"},{"id":"359704","messageId":"02874ECE860811409154E81DA85FBB5884CCBED2@ORSMSX115.amr.corp.intel.com","threadId":"49471","inReplyTo":"20181005162517.GB11254@sigill.intra.peff.net","subject":"RE: [PATCH v3] coccicheck: process every source file at once","fromName":"Keller, Jacob E","fromEmail":"jacob.e.keller@intel.com","sentAt":"2018-10-05T16:53:35Z","receivedAt":"2018-10-05T16:53:38Z","isPatch":true,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"> -----Original Message-----\n> From: Jeff King [mailto:peff@peff.net]\n> Sent: Friday, October 05, 2018 9:25 AM\n> To: SZEDER Gábor \n> Cc: Jacob Keller ; Keller, Jacob E\n> ; Git mailing list \n> Subject: Re: [PATCH v3] coccicheck: process every source file at once\n> \n> On Fri, Oct 05, 2018 at 02:40:48PM +0200, SZEDER Gábor wrote:\n> \n> > On Thu, Oct 04, 2018 at 07:17:47PM -0700, Jacob Keller wrote:\n> > > Junio, do you want me to update the commit message on my side with the\n> > > memory concerns? Or could you update it to mention memory as a noted\n> > > trade off.\n> >\n> > We have been running 'make -j2 coccicheck' in the static analysis\n> > build job on Travis CI, which worked just fine so far. The Travis CI\n> > build environments have 3GB of memory available [1], but, as shown in\n> > [2], with this patch the memory consumption jumps up to about\n> > 1.3-1.8GB for each of those jobs. So with two parallel jobs we will\n> > very likely bump into this limit.\n> >\n> > So this patch should definitely change that build script to run only a\n> > single job.\n> \n> It should still be a net win, since the total CPU seems to drop by a\n> factor of 3-4.\n> \n> Are we OK with saying 1.3-1.8GB is necessary to run coccicheck? That\n> doesn't feel like an exorbitant request for a developer-only tool these\n> days, but I have noticed some people on the list tend to have lousier\n> machines than I do. ;)\n> \n> -Peff\n\nIt's probably not worth trying to make this more complicated and scale up how many files we do at once based on the amount of available memory on the system...\n\nThanks,\nJake\n"},{"id":"359706","messageId":"20181005165901.GE11254@sigill.intra.peff.net","threadId":"49471","inReplyTo":"02874ECE860811409154E81DA85FBB5884CCBED2@ORSMSX115.amr.corp.intel.com","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-05T16:59:01Z","receivedAt":"2018-10-05T16:59:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 05, 2018 at 04:53:35PM +0000, Keller, Jacob E wrote:\n\n> > Are we OK with saying 1.3-1.8GB is necessary to run coccicheck? That\n> > doesn't feel like an exorbitant request for a developer-only tool these\n> > days, but I have noticed some people on the list tend to have lousier\n> > machines than I do. ;)\n> > \n> > -Peff\n> \n> It's probably not worth trying to make this more complicated and scale\n> up how many files we do at once based on the amount of available\n> memory on the system...\n\nYeah, that sounds too complicated. At most I'd give a Makefile knob to\nsay \"spatch in batches of $(N)\". But I'd prefer to avoid even that\ncomplexity if we can.\n\n-Peff\n"},{"id":"359713","messageId":"20181005183904.GV23446@localhost","threadId":"49471","inReplyTo":"20181005162517.GB11254@sigill.intra.peff.net","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-10-05T18:39:04Z","receivedAt":"2018-10-05T18:39:13Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Oct 05, 2018 at 12:25:17PM -0400, Jeff King wrote:\n> On Fri, Oct 05, 2018 at 02:40:48PM +0200, SZEDER Gábor wrote:\n> \n> > On Thu, Oct 04, 2018 at 07:17:47PM -0700, Jacob Keller wrote:\n> > > Junio, do you want me to update the commit message on my side with the\n> > > memory concerns? Or could you update it to mention memory as a noted\n> > > trade off.\n> > \n> > We have been running 'make -j2 coccicheck' in the static analysis\n> > build job on Travis CI, which worked just fine so far. The Travis CI\n> > build environments have 3GB of memory available [1], but, as shown in\n> > [2], with this patch the memory consumption jumps up to about\n> > 1.3-1.8GB for each of those jobs. So with two parallel jobs we will\n> > very likely bump into this limit.\n> > \n> > So this patch should definitely change that build script to run only a\n> > single job.\n> \n> It should still be a net win, since the total CPU seems to drop by a\n> factor of 3-4.\n\nWell, that's true when you have unlimited resources... :) or it's\ntrue even then, when I have just enough resources, but not much\ncontention. After all, Coccinelle doesn't have to parse the same\nheader files over and over again. However, on Travis CI, where who\nknows how many other build jobs are running next to our static\nanalysis, it doesn't seem to be the case.\n\nOn current master with an additional 'time' in front:\n\n time make --jobs=2 coccicheck\n <...>\n 695.70user 50.27system 6:27.88elapsed 192%CPU (0avgtext+0avgdata 91448maxresident)k\n 5976inputs+2536outputs (42major+18411888minor)pagefaults 0swaps\n\n https://travis-ci.org/szeder/git/jobs/437733874#L574\n\nWith this patch, but without -j2 to fit into 3GB:\n\n 960.50user 22.59system 16:23.74elapsed 99%CPU (0avgtext+0avgdata 1606156maxresident)k\n 5976inputs+1320outputs (26major+4548440minor)pagefaults 0swaps\n\n https://travis-ci.org/szeder/git/jobs/437734003#L575\n\nNote that both the runtime and the CPU time increased. (and RSS, of\ncourse)\n\n> Are we OK with saying 1.3-1.8GB is necessary to run coccicheck? That\n> doesn't feel like an exorbitant request for a developer-only tool these\n> days, but I have noticed some people on the list tend to have lousier\n> machines than I do. ;)\n> \n> -Peff\n"},{"id":"359715","messageId":"20181005185050.GW23446@localhost","threadId":"49471","inReplyTo":"20181005165901.GE11254@sigill.intra.peff.net","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-10-05T18:50:50Z","receivedAt":"2018-10-05T18:50:56Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Oct 05, 2018 at 12:59:01PM -0400, Jeff King wrote:\n> On Fri, Oct 05, 2018 at 04:53:35PM +0000, Keller, Jacob E wrote:\n> \n> > > Are we OK with saying 1.3-1.8GB is necessary to run coccicheck? That\n> > > doesn't feel like an exorbitant request for a developer-only tool these\n> > > days, but I have noticed some people on the list tend to have lousier\n> > > machines than I do. ;)\n> > > \n> > > -Peff\n> > \n> > It's probably not worth trying to make this more complicated and scale\n> > up how many files we do at once based on the amount of available\n> > memory on the system...\n> \n> Yeah, that sounds too complicated. At most I'd give a Makefile knob to\n> say \"spatch in batches of $(N)\". But I'd prefer to avoid even that\n> complexity if we can.\n\nBut perhaps one more if-else, e.g.:\n\n if test -n \"$(COCCICHECK_ALL_AT_ONCE)\"; then \\\n \n else\n \n fi\n\nwould be an acceptable compromise? Dunno.\n\n"},{"id":"359716","messageId":"20181005190045.GA17482@sigill.intra.peff.net","threadId":"49471","inReplyTo":"20181005185050.GW23446@localhost","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-05T19:00:45Z","receivedAt":"2018-10-05T19:00:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 05, 2018 at 08:50:50PM +0200, SZEDER Gábor wrote:\n\n> On Fri, Oct 05, 2018 at 12:59:01PM -0400, Jeff King wrote:\n> > On Fri, Oct 05, 2018 at 04:53:35PM +0000, Keller, Jacob E wrote:\n> > \n> > > > Are we OK with saying 1.3-1.8GB is necessary to run coccicheck? That\n> > > > doesn't feel like an exorbitant request for a developer-only tool these\n> > > > days, but I have noticed some people on the list tend to have lousier\n> > > > machines than I do. ;)\n> > > > \n> > > > -Peff\n> > > \n> > > It's probably not worth trying to make this more complicated and scale\n> > > up how many files we do at once based on the amount of available\n> > > memory on the system...\n> > \n> > Yeah, that sounds too complicated. At most I'd give a Makefile knob to\n> > say \"spatch in batches of $(N)\". But I'd prefer to avoid even that\n> > complexity if we can.\n> \n> But perhaps one more if-else, e.g.:\n> \n> if test -n \"$(COCCICHECK_ALL_AT_ONCE)\"; then \\\n> \n> else\n> \n> fi\n> \n> would be an acceptable compromise? Dunno.\n\nThat's OK, too, assuming people would actually want to use it. I'm also\nOK shipping this (with the \"make -j\" fix you suggested) and seeing if\nanybody actually complains. I assume there are only a handful of people\nrunning coccicheck in the first place.\n\n-Peff\n"},{"id":"359717","messageId":"20181005190216.GB17482@sigill.intra.peff.net","threadId":"49471","inReplyTo":"20181005183904.GV23446@localhost","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-05T19:02:16Z","receivedAt":"2018-10-05T19:02:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 05, 2018 at 08:39:04PM +0200, SZEDER Gábor wrote:\n\n> > It should still be a net win, since the total CPU seems to drop by a\n> > factor of 3-4.\n> \n> Well, that's true when you have unlimited resources... :) or it's\n> true even then, when I have just enough resources, but not much\n> contention. After all, Coccinelle doesn't have to parse the same\n> header files over and over again. However, on Travis CI, where who\n> knows how many other build jobs are running next to our static\n> analysis, it doesn't seem to be the case.\n> \n> On current master with an additional 'time' in front:\n> \n> time make --jobs=2 coccicheck\n> <...>\n> 695.70user 50.27system 6:27.88elapsed 192%CPU (0avgtext+0avgdata 91448maxresident)k\n> 5976inputs+2536outputs (42major+18411888minor)pagefaults 0swaps\n> \n> https://travis-ci.org/szeder/git/jobs/437733874#L574\n> \n> With this patch, but without -j2 to fit into 3GB:\n> \n> 960.50user 22.59system 16:23.74elapsed 99%CPU (0avgtext+0avgdata 1606156maxresident)k\n> 5976inputs+1320outputs (26major+4548440minor)pagefaults 0swaps\n> \n> https://travis-ci.org/szeder/git/jobs/437734003#L575\n> \n> Note that both the runtime and the CPU time increased. (and RSS, of\n> course)\n\nI'm not sure what to make of those results. Was the jump in CPU _caused_\nby the patch, or does it independently fluctuate based on other things\nhappening on the Travis servers?\n\nI.e., in the second run, do we know that the time would not have\nactually been worse with the first patch?\n\n-Peff\n"},{"id":"359730","messageId":"20181005195413.GX23446@localhost","threadId":"49471","inReplyTo":"20181005190216.GB17482@sigill.intra.peff.net","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-10-05T19:54:13Z","receivedAt":"2018-10-05T19:54:19Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Oct 05, 2018 at 03:02:16PM -0400, Jeff King wrote:\n> On Fri, Oct 05, 2018 at 08:39:04PM +0200, SZEDER Gábor wrote:\n> \n> > > It should still be a net win, since the total CPU seems to drop by a\n> > > factor of 3-4.\n> > \n> > Well, that's true when you have unlimited resources... :) or it's\n> > true even then, when I have just enough resources, but not much\n> > contention. After all, Coccinelle doesn't have to parse the same\n> > header files over and over again. However, on Travis CI, where who\n> > knows how many other build jobs are running next to our static\n> > analysis, it doesn't seem to be the case.\n> > \n> > On current master with an additional 'time' in front:\n> > \n> > time make --jobs=2 coccicheck\n> > <...>\n> > 695.70user 50.27system 6:27.88elapsed 192%CPU (0avgtext+0avgdata 91448maxresident)k\n> > 5976inputs+2536outputs (42major+18411888minor)pagefaults 0swaps\n> > \n> > https://travis-ci.org/szeder/git/jobs/437733874#L574\n> > \n> > With this patch, but without -j2 to fit into 3GB:\n> > \n> > 960.50user 22.59system 16:23.74elapsed 99%CPU (0avgtext+0avgdata 1606156maxresident)k\n> > 5976inputs+1320outputs (26major+4548440minor)pagefaults 0swaps\n> > \n> > https://travis-ci.org/szeder/git/jobs/437734003#L575\n> > \n> > Note that both the runtime and the CPU time increased. (and RSS, of\n> > course)\n> \n> I'm not sure what to make of those results. Was the jump in CPU _caused_\n> by the patch, or does it independently fluctuate based on other things\n> happening on the Travis servers?\n> \n> I.e., in the second run, do we know that the time would not have\n> actually been worse with the first patch?\n\nRuntimes tend to fluctuate quite a bit more on Travis CI compared to\nmy machine, but not this much, and it seems to be consistent so far.\n\nAfter scripting/querying the Travis CI API a bit, I found that from\nthe last 100 static analysis build jobs 78 did actully run 'make\ncoccicheck' [1], avaraging 470s for the whole build job, with only 4\nbuild job exceeding the 10min mark.\n\nI had maybe 6-8 build jobs running this patch over the last 2-3 days,\nI think all of them were over 15min. (I restarted some of them, so I\ndon't have separate logs for all of them, hence the uncertainty.)\n\n\n1 - There are a couple of canceled build jobs, and we skip the build\n job of branches when they happen to match a tags.\n"},{"id":"359759","messageId":"CA+P7+xpRt1j92m9y0pH-XLQ1_HaUZ97D7GEKJYJQCz83y=6x0Q@mail.gmail.com","threadId":"49471","inReplyTo":"20181005190045.GA17482@sigill.intra.peff.net","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2018-10-05T23:10:08Z","receivedAt":"2018-10-05T23:10:23Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Fri, Oct 5, 2018 at 12:00 PM Jeff King wrote:\n> That's OK, too, assuming people would actually want to use it. I'm also\n> OK shipping this (with the \"make -j\" fix you suggested) and seeing if\n> anybody actually complains. I assume there are only a handful of people\n> running coccicheck in the first place.\n>\n> -Peff\n\nOk. I can go this route if we have consensus on the \"break it and see\nif someone complains\" route.\n\nRegards,\nJake\n"},{"id":"359764","messageId":"8b51c4c0-df51-7639-07fe-74d6ca3b5944@web.de","threadId":"49471","inReplyTo":"20181005190045.GA17482@sigill.intra.peff.net","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2018-10-06T08:42:57Z","receivedAt":"2018-10-06T08:43:12Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 05.10.2018 um 21:00 schrieb Jeff King:\n> On Fri, Oct 05, 2018 at 08:50:50PM +0200, SZEDER Gábor wrote:\n> \n>> On Fri, Oct 05, 2018 at 12:59:01PM -0400, Jeff King wrote:\n>>> On Fri, Oct 05, 2018 at 04:53:35PM +0000, Keller, Jacob E wrote:\n>>>\n>>>>> Are we OK with saying 1.3-1.8GB is necessary to run coccicheck? That\n>>>>> doesn't feel like an exorbitant request for a developer-only tool these\n>>>>> days, but I have noticed some people on the list tend to have lousier\n>>>>> machines than I do. ;)\n>>>>>\n>>>>> -Peff\n>>>>\n>>>> It's probably not worth trying to make this more complicated and scale\n>>>> up how many files we do at once based on the amount of available\n>>>> memory on the system...\n>>>\n>>> Yeah, that sounds too complicated. At most I'd give a Makefile knob to\n>>> say \"spatch in batches of $(N)\". But I'd prefer to avoid even that\n>>> complexity if we can.\n>>\n>> But perhaps one more if-else, e.g.:\n>>\n>> if test -n \"$(COCCICHECK_ALL_AT_ONCE)\"; then \\\n>> \n>> else\n>> \n>> fi\n>>\n>> would be an acceptable compromise? Dunno.\n> \n> That's OK, too, assuming people would actually want to use it. I'm also\n> OK shipping this (with the \"make -j\" fix you suggested) and seeing if\n> anybody actually complains. I assume there are only a handful of people\n> running coccicheck in the first place.\n\nFWIW, my development environment is a virtual machine with 1200MB RAM\nand 900MB swap space. coccicheck takes almost eight minutes\nsequentially, and four and a half minutes with -j4.\n\nUnsurprisingly, it fails after almost three minutes with the patch,\nreporting that it ran out of memory. With 2900MB it fails after almost\ntwo minutes, with 3000MB it succeeds after a good two minutes.\n\ntime(1) says (for -j1):\n\n433.30user 36.17system 7:49.84elapsed 99%CPU (0avgtext+0avgdata 108212maxresident)k\n192inputs+1512outputs (0major+16409056minor)pagefaults 0swaps\n\n129.74user 2.06system 2:13.27elapsed 98%CPU (0avgtext+0avgdata 1884568maxresident)k\n236896inputs+1096outputs (795major+462129minor)pagefaults 0swaps\n\nSo with the patch it's more than three times faster, but needs more\nthan seventeen times more memory. And I need a bigger VM. :-/\n\nRené\n"},{"id":"359789","messageId":"4f705fbc-e1a3-8e27-02ed-39a5c3dcfdcc@drbeat.li","threadId":"49471","inReplyTo":"CA+P7+xoqKG84n5EMKbajuZoXrOKZMudZ6CT-OKzz8XYyTYaCWQ@mail.gmail.com","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Beat Bolli","fromEmail":"dev+git@drbeat.li","sentAt":"2018-10-07T11:36:27Z","receivedAt":"2018-10-07T11:38:53Z","isPatch":true,"sender":{"key":"dev+git@drbeat.li","avatar":"https://avatars.githubusercontent.com/u/21444?v=4"},"body":"On 02.10.18 22:18, Jacob Keller wrote:\n> On Tue, Oct 2, 2018 at 1:07 PM Jacob Keller wrote:\n>>\n>> From: Jacob Keller \n>>\n>> make coccicheck is used in order to apply coccinelle semantic patches,\n>> and see if any of the transformations found within contrib/coccinelle/\n>> can be applied to the current code base.\n>>\n>> Pass every file to a single invocation of spatch, instead of running\n>> spatch once per source file.\n>>\n>> This reduces the time required to run make coccicheck by a significant\n>> amount of time:\n>>\n>> Prior timing of make coccicheck\n>> real 6m14.090s\n>> user 25m2.606s\n>> sys 1m22.919s\n>>\n>> New timing of make coccicheck\n>> real 1m36.580s\n>> user 7m55.933s\n>> sys 0m18.219s\n>>\n>> This is nearly a 4x decrease in the time required to run make\n>> coccicheck. This is due to the overhead of restarting spatch for every\n>> file. By processing all files at once, we can amortize this startup cost\n>> across the total number of files, rather than paying it once per file.\n>>\n>> Signed-off-by: Jacob Keller \n>> ---\n> \n> Forgot to add what changed. I dropped the subshell and \"||\" bit around\n> invoking spatch.\n> \n> Thanks,\n> Jake\n> \n> \n>> Makefile | 6 ++----\n>> 1 file changed, 2 insertions(+), 4 deletions(-)\n>>\n>> diff --git a/Makefile b/Makefile\n>> index df1df9db78da..da692ece9e12 100644\n>> --- a/Makefile\n>> +++ b/Makefile\n>> @@ -2715,10 +2715,8 @@ endif\n>> %.cocci.patch: %.cocci $(COCCI_SOURCES)\n>> @echo ' ' SPATCH $<; \\\n>> ret=0; \\\n>> - for f in $(COCCI_SOURCES); do \\\n>> - $(SPATCH) --sp-file $< $$f $(SPATCH_FLAGS) || \\\n>> - { ret=$$?; break; }; \\\n>> - done >$@+ 2>$@.log; \\\n>> + $(SPATCH) --sp-file $< $(COCCI_SOURCES) $(SPATCH_FLAGS) >$@+ 2>$@.log; \\\n>> + ret=$$?; \\\n>> if test $$ret != 0; \\\n>> then \\\n>> cat $@.log; \\\n>> --\n>> 2.18.0.219.gaf81d287a9da\n>>\n\nWouldn't the following be even simpler?\n\ndiff --git a/Makefile b/Makefile\nindex 5c8307b7c479..a37b2724d526 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -2701,12 +2701,7 @@ endif\n\n %.cocci.patch: %.cocci $(COCCI_SOURCES)\n @echo ' ' SPATCH $<; \\\n- ret=0; \\\n- for f in $(COCCI_SOURCES); do \\\n- $(SPATCH) --sp-file $< $$f $(SPATCH_FLAGS) || \\\n- { ret=$$?; break; }; \\\n- done >$@+ 2>$@.log; \\\n- if test $$ret != 0; \\\n+ if ! $(SPATCH) --sp-file $< $(COCCI_SOURCES) $(SPATCH_FLAGS)\n>$@+ 2>$@.log; \\\n then \\\n cat $@.log; \\\n exit 1; \\\n\nCheers,\nBeat\n\n"},{"id":"359790","messageId":"7aa8efab-66f6-e2a5-9196-6d68872e5e34@drbeat.li","threadId":"49471","inReplyTo":"4f705fbc-e1a3-8e27-02ed-39a5c3dcfdcc@drbeat.li","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Beat Bolli","fromEmail":"dev+git@drbeat.li","sentAt":"2018-10-07T11:49:02Z","receivedAt":"2018-10-07T11:49:08Z","isPatch":true,"sender":{"key":"dev+git@drbeat.li","avatar":"https://avatars.githubusercontent.com/u/21444?v=4"},"body":"On 07.10.18 13:36, Beat Bolli wrote:\n> On 02.10.18 22:18, Jacob Keller wrote:\n>> On Tue, Oct 2, 2018 at 1:07 PM Jacob Keller wrote:\n>>>\n>>> From: Jacob Keller \n>>>\n>>> make coccicheck is used in order to apply coccinelle semantic patches,\n>>> and see if any of the transformations found within contrib/coccinelle/\n>>> can be applied to the current code base.\n>>>\n>>> Pass every file to a single invocation of spatch, instead of running\n>>> spatch once per source file.\n>>>\n>>> This reduces the time required to run make coccicheck by a significant\n>>> amount of time:\n>>>\n>>> Prior timing of make coccicheck\n>>> real 6m14.090s\n>>> user 25m2.606s\n>>> sys 1m22.919s\n>>>\n>>> New timing of make coccicheck\n>>> real 1m36.580s\n>>> user 7m55.933s\n>>> sys 0m18.219s\n>>>\n>>> This is nearly a 4x decrease in the time required to run make\n>>> coccicheck. This is due to the overhead of restarting spatch for every\n>>> file. By processing all files at once, we can amortize this startup cost\n>>> across the total number of files, rather than paying it once per file.\n>>>\n>>> Signed-off-by: Jacob Keller \n>>> ---\n>>\n>> Forgot to add what changed. I dropped the subshell and \"||\" bit around\n>> invoking spatch.\n>>\n>> Thanks,\n>> Jake\n>>\n>>\n>>> Makefile | 6 ++----\n>>> 1 file changed, 2 insertions(+), 4 deletions(-)\n>>>\n>>> diff --git a/Makefile b/Makefile\n>>> index df1df9db78da..da692ece9e12 100644\n>>> --- a/Makefile\n>>> +++ b/Makefile\n>>> @@ -2715,10 +2715,8 @@ endif\n>>> %.cocci.patch: %.cocci $(COCCI_SOURCES)\n>>> @echo ' ' SPATCH $<; \\\n>>> ret=0; \\\n>>> - for f in $(COCCI_SOURCES); do \\\n>>> - $(SPATCH) --sp-file $< $$f $(SPATCH_FLAGS) || \\\n>>> - { ret=$$?; break; }; \\\n>>> - done >$@+ 2>$@.log; \\\n>>> + $(SPATCH) --sp-file $< $(COCCI_SOURCES) $(SPATCH_FLAGS) >$@+ 2>$@.log; \\\n>>> + ret=$$?; \\\n>>> if test $$ret != 0; \\\n>>> then \\\n>>> cat $@.log; \\\n>>> --\n>>> 2.18.0.219.gaf81d287a9da\n>>>\n> \n> Wouldn't the following be even simpler?\n> \n> diff --git a/Makefile b/Makefile\n> index 5c8307b7c479..a37b2724d526 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -2701,12 +2701,7 @@ endif\n> \n> %.cocci.patch: %.cocci $(COCCI_SOURCES)\n> @echo ' ' SPATCH $<; \\\n> - ret=0; \\\n> - for f in $(COCCI_SOURCES); do \\\n> - $(SPATCH) --sp-file $< $$f $(SPATCH_FLAGS) || \\\n> - { ret=$$?; break; }; \\\n> - done >$@+ 2>$@.log; \\\n> - if test $$ret != 0; \\\n> + if ! $(SPATCH) --sp-file $< $(COCCI_SOURCES) $(SPATCH_FLAGS) \n>> $@+ 2>$@.log; \\\n\nThe \"If !\" and the output redirection should be on one line,\nobviously... Sorry about this.\n\nBeat\n"},{"id":"359891","messageId":"20181009031116.GC6250@sigill.intra.peff.net","threadId":"49471","inReplyTo":"8b51c4c0-df51-7639-07fe-74d6ca3b5944@web.de","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-09T03:11:16Z","receivedAt":"2018-10-09T03:11:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 06, 2018 at 10:42:57AM +0200, René Scharfe wrote:\n\n> > That's OK, too, assuming people would actually want to use it. I'm also\n> > OK shipping this (with the \"make -j\" fix you suggested) and seeing if\n> > anybody actually complains. I assume there are only a handful of people\n> > running coccicheck in the first place.\n> \n> FWIW, my development environment is a virtual machine with 1200MB RAM\n> and 900MB swap space. coccicheck takes almost eight minutes\n> sequentially, and four and a half minutes with -j4.\n> \n> Unsurprisingly, it fails after almost three minutes with the patch,\n> reporting that it ran out of memory. With 2900MB it fails after almost\n> two minutes, with 3000MB it succeeds after a good two minutes.\n> \n> time(1) says (for -j1):\n> \n> 433.30user 36.17system 7:49.84elapsed 99%CPU (0avgtext+0avgdata 108212maxresident)k\n> 192inputs+1512outputs (0major+16409056minor)pagefaults 0swaps\n> \n> 129.74user 2.06system 2:13.27elapsed 98%CPU (0avgtext+0avgdata 1884568maxresident)k\n> 236896inputs+1096outputs (795major+462129minor)pagefaults 0swaps\n> \n> So with the patch it's more than three times faster, but needs more\n> than seventeen times more memory. And I need a bigger VM. :-/\n\nYuck. :) So if we want to take this as a complaint, then I guess we can\njump straight to implementing the fallback to the existing behavior\n(though it may be worth it for you to expand your VM to get the\ndecreased CPU time).\n\nI'm still puzzled by Gábor's counter-intuitive CI numbers, though.\n\n-Peff\n"},{"id":"359892","messageId":"20181009031542.GD6250@sigill.intra.peff.net","threadId":"49471","inReplyTo":"20181005195413.GX23446@localhost","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-09T03:15:42Z","receivedAt":"2018-10-09T03:15:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 05, 2018 at 09:54:13PM +0200, SZEDER Gábor wrote:\n\n> Runtimes tend to fluctuate quite a bit more on Travis CI compared to\n> my machine, but not this much, and it seems to be consistent so far.\n> \n> After scripting/querying the Travis CI API a bit, I found that from\n> the last 100 static analysis build jobs 78 did actully run 'make\n> coccicheck' [1], avaraging 470s for the whole build job, with only 4\n> build job exceeding the 10min mark.\n> \n> I had maybe 6-8 build jobs running this patch over the last 2-3 days,\n> I think all of them were over 15min. (I restarted some of them, so I\n> don't have separate logs for all of them, hence the uncertainty.)\n\nSo that's really weird and counter-intuitive, since we should be doing\nstrictly less work. I know that spatch tries to parallelize itself,\nthough from my tests, 1.0.4 does not. I wonder if the version in Travis\ndiffers in that respect and starts too many threads, and the extra time\nis going to contention and context switches.\n\nHave you tried passing \"-j1\" to spatch? My 1.0.4 does not even recognize\nit.\n\nThat seems like a pretty unlikely explanation to me, but I am having\ntrouble coming up with another one.\n\nI guess the other plausible thing is that the extra memory is forcing us\ninto some slower path. E.g., a hypervisor may even be swapping,\nunbeknownst to the child OS, and it gets accounted in the child OS as\n\"boy, that memory load was really slow\", which becomes used CPU.\n\nThat actually sounds more credible to me.\n\n-Peff\n"},{"id":"360008","messageId":"20181010114441.GD23446@szeder.dev","threadId":"49471","inReplyTo":"20181009031542.GD6250@sigill.intra.peff.net","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-10-10T11:44:41Z","receivedAt":"2018-10-10T11:44:48Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Mon, Oct 08, 2018 at 11:15:42PM -0400, Jeff King wrote:\n> On Fri, Oct 05, 2018 at 09:54:13PM +0200, SZEDER Gábor wrote:\n> \n> > Runtimes tend to fluctuate quite a bit more on Travis CI compared to\n> > my machine, but not this much, and it seems to be consistent so far.\n> > \n> > After scripting/querying the Travis CI API a bit, I found that from\n> > the last 100 static analysis build jobs 78 did actully run 'make\n> > coccicheck' [1], avaraging 470s for the whole build job, with only 4\n> > build job exceeding the 10min mark.\n> > \n> > I had maybe 6-8 build jobs running this patch over the last 2-3 days,\n> > I think all of them were over 15min. (I restarted some of them, so I\n> > don't have separate logs for all of them, hence the uncertainty.)\n> \n> So that's really weird and counter-intuitive, since we should be doing\n> strictly less work. I know that spatch tries to parallelize itself,\n> though from my tests, 1.0.4 does not. I wonder if the version in Travis\n> differs in that respect and starts too many threads, and the extra time\n> is going to contention and context switches.\n\nI don't think it does any parallel work.\n\nHere is the timing again from my previous email:\n\n 960.50user 22.59system 16:23.74elapsed 99%CPU (0avgtext+0avgdata 1606156maxresident)k\n\nNotice that 16:23 is 983s, and that it matches the sum of the user and\nsystem times. I usually saw this kind of timing with CPU-intensive\nsingle-threaded programs, and if there were any parallelization, then I\nwould expect the elapsed time to be at least somewhat smaller than the\nother two.\n\n> Have you tried passing \"-j1\" to spatch? My 1.0.4 does not even recognize\n> it.\n\nI have just gave it a try, but the v1.0.0 on Travis CI errored out with\n\"unknown option `-j'.\n\n https://travis-ci.org/szeder/git/jobs/439532822#L566\n\n> That seems like a pretty unlikely explanation to me, but I am having\n> trouble coming up with another one.\n> \n> I guess the other plausible thing is that the extra memory is forcing us\n> into some slower path. E.g., a hypervisor may even be swapping,\n> unbeknownst to the child OS, and it gets accounted in the child OS as\n> \"boy, that memory load was really slow\", which becomes used CPU.\n> \n> That actually sounds more credible to me.\n> \n> -Peff\n"},{"id":"360025","messageId":"20181010135952.GA2933@sigill.intra.peff.net","threadId":"49471","inReplyTo":"20181010114441.GD23446@szeder.dev","subject":"Re: [PATCH v3] coccicheck: process every source file at once","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-10T13:59:52Z","receivedAt":"2018-10-10T13:59:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 10, 2018 at 01:44:41PM +0200, SZEDER Gábor wrote:\n\n> > So that's really weird and counter-intuitive, since we should be doing\n> > strictly less work. I know that spatch tries to parallelize itself,\n> > though from my tests, 1.0.4 does not. I wonder if the version in Travis\n> > differs in that respect and starts too many threads, and the extra time\n> > is going to contention and context switches.\n> \n> I don't think it does any parallel work.\n> \n> Here is the timing again from my previous email:\n> \n> 960.50user 22.59system 16:23.74elapsed 99%CPU (0avgtext+0avgdata 1606156maxresident)k\n> \n> Notice that 16:23 is 983s, and that it matches the sum of the user and\n> system times. I usually saw this kind of timing with CPU-intensive\n> single-threaded programs, and if there were any parallelization, then I\n> would expect the elapsed time to be at least somewhat smaller than the\n> other two.\n\nAh, right, I should have been able to figure that out myself. So scratch\nthat theory. My \"hypervisor stalling our memory reads\" theory is still\nplausible, but I don't know how we would test it.\n\nI guess in some sense it doesn't matter. If it's slower, we're not\nlikely to be able to fix that. So I guess we just need the fallback to\nthe current behavior.\n\n-Peff\n"}]}