kva size on amd64

[Andriy Gapon]

on 01/02/2013 11:57 Konstantin Belousov said the following:
> On Fri, Feb 01, 2013 at 11:47:23AM +0200, Andriy Gapon wrote:
> I think that the rework of the ZFS memory management should remove the
> use of uma or kmem_alloc() at all. From what I heard in part from you,
> there is no reason to keep the filesystem caches mapped full time.
> 
> I hope to commit shortly a facilities that would allow ZFS to easily
> manage copying for i/o from the unmapped set of pages. The checksumming
> you mentioned would require some more work, but this does not look
> unsurmountable. Having ZFS use raw vm_page_t for caching would also
> remove the pressure on KVA.

Yes, this would be perfect.

I think that perhaps we also need some helper API to manage groups of pages.
E.g. right now ZFS can malloc or uma_zalloc a 32KB buffer and it would have a
single handle (a pointer to the mapped pages).  This is convenient.  So it would
be useful to have some representation for e.g. N non-contiguous unmapped
physical pages that logically represent M KB of some contiguous data.
An opposite issue is e.g packing 4 (or is it three) unrelated 512-byte blocks
into a single page as is possible with uma.

So perhaps some "unmapped uma"?

Another, purely ZFS issue is that ZFS code freely accesses buffers with
metadata.  Adding mapping+unmapping code around such all accesses could be
cumbersome.

All in all, this is not a quick project, IMO.

>> P.S.
>> BTW, do I understand correctly that the reservation of kernel page tables
>> happens through vm_map_insert -> pmap_growkernel ?
> 
> Yes. E.g. kmem_suballoc->vm_map_find->vm_map_insert->pmap_growkernel.
> 

Thank you!

-- 
Andriy Gapon