On 11/19/06, Chuck Silvers <chuq@chuq.com> wrote:
> On Mon, Nov 13, 2006 at 09:46:27AM -0800, Jason Thorpe wrote:
> > The right thing for you to do is to simply define your own pool page
> > allocator for your tmpfs pools, and use uvm_km_alloc(kernel_map, ...,
> > UVM_KMF_PAGEABLE) within that allocator to allocate the pages.
>
>
> when accessing non-wired memory from the kernel, all access must be through
> fault-safe mechanisms such as kcopy(), so that the kernel doesn't panic if
> reading the page from its backing store fails.  so tmpfs would either need
> to do that for every access to any item from such a pageable pool, or else
> re-wire each pageable page while accessing it.  dealing with all the error
> cases involved in either of these approaches seems like a nightmare.
> also, think of how MP locking will make this more complicated...
> you can't be holding any spin locks when you do something that might
> trigger a page-fault.

I've just hit that specific problem while trying Jason's approach
(thanks LOCKDEBUG!) and was wondering if it was possible to solve it.
Wouldn't replacing the appropriate spinlocks with regular locks help
in that case?

Also how can reading the page from its backing store fail?  I mean, if
that happens, you've got a serious problem with your swap and you're
likely going to have other problems anyway, isn't it?  Hmm, but then
maybe the kernel will stay up...

> I think it would be much better to simply use an aobj as backing store for
> data that looks very much like a traditional disk-based file system.
> paging the kernel in-memory data structures themselves creates a snarly mess.

Keep in mind that the main tmpfs goal was to use data structures that
are not bound to a disk/block-like scheme (e.g. directories directly
point to entries by using pointers, not "indirect" references, etc.).

Anyway.  I don't know yet how to "use" an aobj; as far as I can see
one has to map a window over it using ubc_alloc and then access the
data.  Is it there any easier -- and more transparent -- way?
Because, if not, this would require reviewing all accesses to
metadata... (not that it oughtn't be done, but before doing the work I
would like to know if I'm on the right track).

Thanks.

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/