[lkml]   [2005]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectanother reason to add openat in the kernel: efficiency
    Miklos Szeredi wrote:
    > What's wrong with using '/proc/self/fd/N' to implement [openat et al]?

    It's great that we can emulate openat and related fd-relative
    functions using /proc/self/fd/N/FILE, but that is markedly less
    efficient than a native implementation.

    Here's some real data for comparison.
    The problem: remove a just-created hierarchy named
    /t/z/z/.../z (1,000,000 levels deep) residing on a tmpfs file system.

    Using GNU rm -rf (from coreutils-5.93[1]), that takes about 14s wall clock
    time on an otherwise idle system running 2.6.14. The 5.93 implementation
    uses open, fchdir, fstat, opendir/readdir, unlink, etc. to do its job:
    i.e., no openat-related functions.

    Compare that with GNU rm from the latest CVS sources[2], now f?chdir-free,
    using /proc-based openat emulation (including emulation of fdopendir[3],
    fstatat, and unlinkat). Here, the time required about 35 seconds:
    more than double. Even after rewriting the emulation code not to use
    snprintf, the resulting times were still about 30s.

    Contrast that with Solaris 9 (with kernel-provided openat, fstatat,
    fdopendir, etc.), where the openat-based implementation takes
    20% *less* time than the 5.93 implementation.

    Sure, there may well be other factors that explain some of the difference,
    but it'd be nice to avoid the added time and space(stack) overhead of
    encoding and decoding each /proc-relative file name. Of course,
    syscall-based interfaces also have the advantage of working even if
    /proc is not accessible.


    [3] It's a shame to have to emulate fdopendir via `opendir ("/proc/...',
    but that's only temporary, while we wait for glibc-with-fdopendir
    to become more mainstream.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-27 23:09    [W:0.020 / U:8.132 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site