bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: should GNU install call matchpathcon by default?


From: Eric Paris
Subject: Re: should GNU install call matchpathcon by default?
Date: Tue, 20 May 2008 17:44:12 -0400

On Tue, May 20, 2008 at 12:13 PM, Jim Meyering <address@hidden> wrote:
> Stephen Smalley <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]