Re: should GNU install call matchpathcon by default?

[Jim Meyering]

"Eric Paris" <address@hidden> wrote:
> 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?

For the single-file case, the patch I pushed makes no performance
difference (assuming the if-0'd code is enabled), since matchpathcon
is called only once.

In the multi-file case, the pre-patch performance penalty for enabling
the ifdef'd-out code would range from probably-immeasurable (for just
2 or 3 files) to infinite, with enough files to make install exhaust
virtual memory.