Re: [PATCH 04/23] vfs: Introduce infrastructure for revoking a file

Nick Piggin [off-list ref] writes:

quoted

In addition for a complete solution we need:
- A reliable way the file structures that we need to revoke.
- To wait for but not tamper with ongoing file creation and cleanup.
- A guarantee that all with user space controlled duration are removed.

The file_hotplug_lock has a very unique implementation necessitated by
the need to have no performance impact on existing code.  Classic locking

Well, it isn't no performance impact. Function calls, branches, icache
and dcache...

Practically none.

Everything I could measure was in the noise.  It is cheaper than any serializing
locking primitive.  I ran both lmbench and did some microbenchmark testing.
So I know on the fast path the overhead is minimal.  Certainly less than  what
we are doing in sysfs and proc today.

Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

On Tue, Jun 02, 2009 at 03:56:02PM -0700, Eric W. Biederman wrote:

Nick Piggin [off-list ref] writes:

quoted

quoted

In addition for a complete solution we need:
- A reliable way the file structures that we need to revoke.
- To wait for but not tamper with ongoing file creation and cleanup.
- A guarantee that all with user space controlled duration are removed.

The file_hotplug_lock has a very unique implementation necessitated by
the need to have no performance impact on existing code.  Classic locking

Well, it isn't no performance impact. Function calls, branches, icache
and dcache...

Practically none.

OK that's different from none. There is obviously overhead.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>