On Tue, May 20, 2008 at 12:13 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > Stephen Smalley <[EMAIL PROTECTED]> wrote: > ... >> This issue came up recently again, see: >> https://bugzilla.redhat.com/show_bug.cgi?id=447410 >> >> It appears that the patch that was merged into coreutils ends up calling >> matchpathcon_init_prefix() for each file being installed rather than >> once upon startup, and without calling matchpathcon_fini() to free the >> memory allocated by each matchpathcon_init_prefix() call. >> >> That makes it slower than necessary and leaks memory. >> >> See the bug report for the discussion. >> >> Can we get this corrected in the upstream coreutils? Thanks. > > Thanks for letting me know. The patch below should do the job. > I didn't bother calling matchpathcon_fini, since its 6MB buffer > is still reachable. > > For now, I'm leaving that code ifdef'd out, because the performance > penalty is still too high even on rawhide, when performing a few hundred > to a thousand separate install commands (about a 20x hit, when > installing to /usr). For reference, I did this: > > # matchpathcon code all ifdef'd out: > $ touch k; time ( for i in $(seq 200); do; install k /usr/tmp/k ;done ) > 0.08s user 0.30s system 97% cpu 0.391 total > # matchpathcon code in use: > $ touch k; time ( for i in $(seq 200); do; ./ginstall k /usr/tmp/k ;done ) > 7.19s user 1.62s system 99% cpu 8.840 total
Just wondering, how much was the perf penalty before this patch? -Eric _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
