Date: Thu, 30 Apr 2009 16:52:05 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, Julian Bangert <julidaoc@online.de>, Julian Elischer <julian@elischer.org>, Kevin Day <toasty@dragondata.com> Subject: Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation Message-ID: <1241128325.1848.0.camel@balrog.2hip.net> In-Reply-To: <200904301736.52325.jhb@freebsd.org> References: <op.us35euemeer2kn@server2go> <1240962328.2021.10.camel@wombat.2hip.net> <49F79841.9030702@elischer.org> <200904301736.52325.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-ZFJl4dhNjBf/ZVMBvz0B Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-04-30 at 17:36 -0400, John Baldwin wrote: > On Tuesday 28 April 2009 7:58:57 pm Julian Elischer wrote: > > Robert Noland wrote: > > > On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: > > >> On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: > > >> > > >>> Hello, > > >>> > > >>> I am currently trying to work a bit on the remaining "missing =20 > > >>> feature" that NVIDIA requires (=20 > http://wiki.freebsd.org/NvidiaFeatureRequests=20 > > >>> or a back post in this ML) - the improved mmap system call. > >=20 > >=20 > > you might check with jhb (john Baldwin) as I think (from his > > p4 work) that he may be doing something in this area in p4. >=20 > After some promptings from Robert and his needs for Xorg recently I did s= tart=20 > hacking on this again. However, I haven't tested it yet. What I have do= ne=20 > so far is in //depot/user/jhb/pat/... and it does the following: >=20 > 1) Adds a vm_cache_mode_t. Each arch defines the valid values for this (= I've=20 > only done the MD portions of this work for amd64 so far). Every arch mus= t at=20 > least define a value for VM_CACHE_DEFAULT. >=20 > 2) Stores a cache mode in each vm_map_entry struct. This cache mode is t= hen=20 > passed down to a few pmap functions: pmap_object_init_pt(),=20 > pmap_enter_object(), and pmap_enter_quick(). Several vm_map routines suc= h as=20 > vm_map_insert() and vm_map_find() now take a cache mode to use when addin= g a=20 > new mapping. >=20 > 3) Each VM object stores a cache mode as well (defaults to VM_CACHE_DEFAU= LT). =20 > When a VM_CACHE_DEFAULT mapping is made of an object, the cache mode of t= he=20 > object is used. >=20 > 4) A new VM object type: OBJT_SG. This object type has its own pager tha= t is=20 > sort of like the device pager. However, instead of invoking d_mmap() to=20 > determine the physaddr for a given page, it consults a pre-created=20 > scatter/gather list (an ADT from my branch for working on unmapped buffer= =20 > I/O) to determine the backing physical address for a given virtual addres= s. >=20 > 5) A new callback for device mmap: d_mmap_single(). One of the features = of=20 > this is that it can return a vm_object_t to be used to satisfy the mmap()= =20 > request instead of using the device's device pager VM object. >=20 > 6) A new mcache() system call similar to mprotect(), except that it chang= es=20 > the cache mode of an address range rather than the protection. This may = not=20 > be all that useful really. >=20 > Given all this, a driver could do the following to map a "thing" as WC in= both=20 > userland and the kernel: >=20 > 1) When it learns about a "thing" it creates a SG list to describe it. I= f=20 > the "thing" consists of userland pages, it has to wire the pages first. = The=20 > driver can use vm_allocate_pager() to create a OBJT_SG VM object. It set= s=20 > the object's cache mode to VM_CACHE_WC (if the arch supports that). >=20 > 2) When userland wants to map the "thing" it does a device mmap() with a=20 > proper length and a file offset that is a cookie for the "thing". The de= vice=20 > driver's d_mmap_single() recognizes the magic file offset and returns=20 > the "thing"'s VM object. Since the mapping info is now part of a normal=20 > object mapping, it will go away via munmap(), etc. The driver no longer = has=20 > to do weird gymnastics to invalidate mappings from its device pager=20 > as "transient" mappings are no longer stored in the device pager. >=20 > 3) When the driver wants to map the "thing" into the kernel, it can use=20 > vm_map_find() to insert the "thing"'s VM object into kernel map. >=20 > And I think that is all there is to it. I need to test this somehow to m= ake=20 > sure though, and make sure this meets the needs of Robert and Nvidia. I think this sounds pretty good... I need to get my perforce foo up to speed so I can try it out... robert. --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD --=-ZFJl4dhNjBf/ZVMBvz0B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkn6HYQACgkQM4TrQ4qfROOQZACfTlbG6blWYjN1761Mnrc7LDM3 2CUAoIZVk1BnMN1wfacpbbpQAMDNstFa =ZyU1 -----END PGP SIGNATURE----- --=-ZFJl4dhNjBf/ZVMBvz0B--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1241128325.1848.0.camel>