Re: [bug-gnu-libiconv] a performance issue

[Bruno Haible]

Hi,

Keyo Jin wrote:
> I am new here and I have a stupid question.  the reason I have that
> question is, when we did some evaluation for charset transcoding in HHVM
> (which finally call glibc iconv library).  we found the CPU utilization
> stuck into the kernel _raw_spin_lock and 80% CPU utilization is that
> spinlock.
> 
> I checked the call graph:
> HPHP::php_iconv_string => iconv_open =>__gconv_open =>
> __gconv_find_transform ( __gconv_lookup_cache) =>  lll_lock =>
> (lowlevellock.h) => __lll_lock_wait_private ()
> 
> and all the way to _raw_spin_lock from kernel side.
> 
> the lock I believe is from iconv library lock:
> 
> in function: __gconv_find_transform:
>  /* Acquire the lock.  */
>   __libc_lock_lock (__gconv_lock);
> 
>   result = __gconv_lookup_cache (toset, fromset, handle, nsteps, flags);
>   if (result != __GCONV_NODB)
>     {
>       /* We have a cache and could resolve the request, successful or not.
> */
>       __libc_lock_unlock (__gconv_lock);
>       return result;
>     }
> 
> and in iconv_close, there is such lock used to release the step buffer as
> well.   but I think the step buffer is thread private, right ?
> 
> I checked the code  a little bit and don't understand the reason we used
> lock here.   I am quite sure I missed something but anyone could educate me
> on this ?
> 
> is there any other way to avoid to use lock here ?

This question is actually a bug report, and it is about GNU libc, not
GNU libiconv. Therefore the right place to report it is the GNU libc
tracker https://sourceware.org/bugzilla/ .

The question is not stupid at all. When you see 80% CPU utilization from
a spin lock, it really looks like a bug.

Bruno