On Wed, 13 Aug 2008 14:57:44 -0400
Eric Paris <eparis@redhat.com> wrote:

quoted text
> > for the open() case, I would argue that you don't need synchronous
> > behavior as long as the read() case is synchronous. I can imagine
> > that open() kicks off an async scan, and if it's done by the time
> > the first read() happens, no blocking at all happens.
> 
> An interesting addition.  Trying to keep these queues of events gets
> much more complex, but if people really think the open to read race is
> that important I've always said it wasn't impossible to close.

it's not "just" about open-to-read race.
it's about open being non-blocking, and if read is not immediate, never
hitting the latency at all.

The real point is that "read" is the actual point  you want to
intercept, not "open" (you even wrote that in your description).. so
why not just do that ?
 The open case then is just a performance optimization.


quoted text
> > Open questions now are
> > 4) do we have the kernel kick off an async scan in open() or do we
> > have glibc do this
> > 5) do we have the kernel do the sync scan on read/mmap/.. or do we
> > have glibc do this
> 
> scan on mmap read?  How do I implement this?  

on calling mmap(); not at fault time.


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/