Re: [RFC][PATCH] inotify 0.10.0

[Paul Jackson]

> This changes an O(1) process to O(N),

At the microlevel, yes.  But:

 1) If one takes as the "unit of measurement" the number of
    system calls made, it's more like O(N/128), given that
    one might average 128 directory entries per getdents()
    call.

 2) This can be cached, with user code mapping inode->d_ino
    to d_name, and then the cached name checked with a single
    stat(2) call to ensure it wasn't stale.

Be leary of micro optimizations imposing a poorer design, especially
across major API boundaries.  Simply waving "O(N)" in our face may not
be adequately persuasive.  You might need a compelling performance
analysis, showing that you can only meet critical goals by passing the
name.  Such analysis may already be intuitively obvious to you.  If it's
already earlier on this thread, don't hesitate to tell me where to go
back and read it.  But right now I am unaware of any such compelling
need.

And there is a long history of pain in Unix dealing with variable length
return values.  Much better to deal with that entirely in user space
code under your control, than to have to align kernel and glibc code in
addition to your code, to get something fixed.  More often than not,
you will end up with faster code when you control the details, than if
you have to align heaven and earth to make changes.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@xxxxxxx> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/