src/winsup/cygwin ChangeLog fhandler_proc.cc f ...
Thu Oct 9 15:07:00 GMT 2014
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
> 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
> 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...
Size: 539 bytes
Desc: OpenPGP digital signature
More information about the Cygwin-developers