src/winsup/cygwin ChangeLog fhandler_proc.cc f ...

[Eric Blake]

On 10/09/2014 08:51 AM, Corinna Vinschen wrote:
>> The whole point of d_type is for optimization, to tell a process when it
>> can avoid the overhead of an lstat() because the system was able to
>> obtain the information in a cheaper manner.  But if you have to resort
>> to an lstat() to get the information, then you are wasting cycles on the
>> case of a user that doesn't care about d_type.  I'd rather we always
>> return DT_UNKNOWN if the only way we'd get a better type is by calling
>> lstat().
> 
> I see.  The idea here was to try and, at least on my machine, it
> was still *very* fast, likely because the whole thing occurs only
> in globally allocated memory and there's no disk access or paging
> involved.
> 
> The question is, what exactly do we lose?  /proc/sys isn't often
> accessed at all (I guess) and what could be gained?  Yaakov asked
> for setting d_type under /proc, so he might enlighten us which
> tools make heavy use of the stuff, so the net gain is > 0...

Some modes of 'find' and 'ls' (such as ls -F) are faster if d_type is
accurate (because they avoided an lstat); there, returning DT_UNKNOWN
requires the lstat.  In other cases (like ls -l) an lstat is always
required.  Anywhere that lstat is slow, embedding an lstat into d_type
determination as well as a followup lstat is going to make directory
traversal twice as slow (well, maybe the second call is faster because
of caching effects); conversely, anywhere that lstat is not required by
the caller, it is wasted effort during the readdir.  But as you say,
lstat in /proc/sys is mostly stuff in memory and already fast, so maybe
it doesn't hurt to leave it in.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 539 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20141009/9a27efc5/attachment.sig>