Re: Unreliable BFD caching heuristic

[Pedro Alves <palves at redhat dot com>]

On 11/25/2013 05:45 PM, Luis Machado wrote:
> On 11/21/2013 03:58 PM, Pedro Alves wrote:
>> On 11/21/2013 05:39 PM, Luis Machado wrote:
>>> Do you have any proposals on ways to improve this heuristic?
>>
>> Compare st_ino/st_dev, and don't share if the system doesn't
>> provide meaningful bfd_stat data?
>>
>> symfile.c:separate_debug_file_exists does this already,
>> and then does a CRC check if all else fails.  Not sure
>> whether the CRC part would be a good idea here.
>>
> 
> I don't think the inode and device information are portable enough for 
> us to use.

bfd sharing is a memory optimization.  That's why I suggested
to not share if not possible to tell (efficiently and) reliably.
Comparing st_ino/st_dev between two files is the standard check
to use to check whether two files are the same.  I don't think we
should penalize systems/filesystems that _can_ do this check in the name
of portability.  Only if that fails would we defer to possibly
more expensive fallbacks, like separate_debug_file_exists.

> 
> The file CRC seems more appropriate in terms of portability, but we need 
> to open the bfd, check the CRC and (maybe) close it if we find a cached 
> entry. Sounds like a potential performance drawback, but it is more 
> reliable IMO.

Right, that's why I wasn't sure it'd be a good idea.  Some sort of
fingerprinting like Maciej suggested has potential for being cheaper.
As usual when considering optimizations, it's a code/memory balance.
We can either always optimize for memory and maybe be slow
sometimes, or always optimize for speed, and use more memory
sometimes.  The trick is in finding the sweet spot in between.

> We can't rely on the timestamp due to some filesystems having 1 second 
> or 2 seconds resolution. That doesn't seem enough.

-- 
Pedro Alves