Date: Fri, 01 Feb 2013 12:52:42 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: alc@FreeBSD.org, freebsd-arch@FreeBSD.org, Alan Cox <alan.l.cox@gmail.com>, Alan Cox <alc@rice.edu> Subject: Re: kva size on amd64 Message-ID: <510B9E7A.1070709@FreeBSD.org> In-Reply-To: <20130201095735.GM2522@kib.kiev.ua> References: <507E7E59.8060201@FreeBSD.org> <51098743.2050603@FreeBSD.org> <CAJUyCcOvHXauk76LnahQPGmdcHbkDOiR1_=4w%2BDW=sZ6i6EJ%2BA@mail.gmail.com> <510A2C09.6030709@FreeBSD.org> <510AB848.3010806@rice.edu> <510B8F2B.5070609@FreeBSD.org> <20130201095735.GM2522@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?510B9E7A.1070709>