Date: Mon, 9 May 2011 21:12:43 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: alc@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon <avg@freebsd.org>, multimedia@freebsd.org Subject: Re: dsp mmap change Message-ID: <20110509181243.GI48734@deviant.kiev.zoral.com.ua> In-Reply-To: <201105091338.25086.jhb@freebsd.org> References: <4DC3B764.4030801@FreeBSD.org> <201105090945.05130.jhb@freebsd.org> <BANLkTin%2B6zvOnNk67f93pFO%2BA=VZPmWw%2BQ@mail.gmail.com> <201105091338.25086.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--sF4+LqaTi7T9hg64 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 09, 2011 at 01:38:24PM -0400, John Baldwin wrote: > On Monday, May 09, 2011 11:35:07 am Alan Cox wrote: > > On Mon, May 9, 2011 at 8:45 AM, John Baldwin <jhb@freebsd.org> wrote: > >=20 > > > On Saturday, May 07, 2011 3:16:25 pm Kostik Belousov wrote: > > > > On Fri, May 06, 2011 at 04:16:40PM -0400, John Baldwin wrote: > > > > > On Friday, May 06, 2011 10:04:28 am Kostik Belousov wrote: > > > > > > On Fri, May 06, 2011 at 04:38:00PM +0300, Andriy Gapon wrote: > > > > > > > on 06/05/2011 16:32 Kostik Belousov said the following: > > > > > > > > On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrot= e: > > > > > > > >> > > > > > > > >> I would like to ask for a review and/or testing of the fol= lowing > > > patch: > > > > > > > >> http://people.freebsd.org/~avg/dev_dsp_mmap.diff > > > > > > > >> > > > > > > > >> It's supposed to fix an issue described here: > > > > > > > >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2011- > > > > > February/011691.html > > > > > > > >> > > > > > > > >> In short, the following pseudo-code should do the right th= ing: > > > > > > > >> fd =3D open(/dev/dsp, O_RDWR); > > > > > > > >> mmap(PROT_READ, fd); > > > > > > > >> mmap(PROT_WRITE, fd); > > > > > > > >> > > > > > > > >> Thank you! > > > > > > > > > > > > > > > > I think that you have to call PCM_GIANT_LEAVE() when return= ing > > > > > > > > EINVAL on the vm_pager_alloc() failure. > > > > > > > > > > > > > > Yes, thank you. > > > > > > > > > > > > > > > Your patch hardcodes an assumption that sndbufs are always > > > > > > > > contiguous. I was unable to convince myself that this is tr= ue. > > > > > > > > > > > > > > I think that this should be true for the case when DMA is use= d? > > > > > > In the current driver, yes, but there is nothing that theoretic= ally > > > > > > prevents scatter-gather from be used. > > > > > > > > > > You could "fix" this by creating an sglist (via sglist_build()) a= nd an > > > > > OBJT_SG VM object that the d_mmap_single callback returned. I wi= sh > > > there > > > > > was a cleaner way to just create a VM object and populate it with= pages > > > > > though, and then use vm_map_insert() to map it into the kernel ra= ther > > > > > than the more roundabout method of OBJT_SG. > > > > > > > > You cannot have one page inserted into two vm objects. Contigmalloc= () > > > > inserts the allocated pages into kernel_object. > > > > > > Yes, I would want to allocate N unmapped pages and stuff them into a = VM > > > object that can then be mapped into the kernel and/or into user mappi= ngs. > > > This would be a much cleaner approach for the nvidia driver for examp= le. > > > > > > > > There is a relatively new function, vm_object_populate(), that allocate= s a > > collection of pages, inserts them into a vm object, and validates them = for > > use. This function exits in FreeBSD 7.x, 8.x, and HEAD. >=20 > Hmm, is there a way to specify restrictions on the pages allocated simila= r to > what contigmalloc() supports (e.g. being able to allocate pages in the lo= wer > 4GB is something the Nvidia driver needs)? >=20 > IOW, a method about like contigmalloc() that returned a VM object holding > pages meeting the desired restrictions but didn't necessarily map the > pages. kmem_alloc_attr() is close to this except it always inserts the > pages into the kernel_object and always maps the pages into the address s= pace. >=20 For GEM, that needs something very similar, I just allocate the swap object, and then do vm_page_grab() over all range. In fact, I never need the full kernel mapping of the object into the KVA using physical addresses, it is enough to do only per-page temporal mappings with sfbuf. On the other hand, both usermode and kernelmode need to access the pages through the aperture remap. Usermode might need to establish several mappings for one GTT page, and this causes troubles because pmap_remove_all() does not work on the fictitious pages. [You was on Cc:]. Other then that, and the fact that vm_page_grab() cannot satisfy the restrictions on the page placement in the physical space, normal swap object is enough for much more complicated device then Azalia. --sF4+LqaTi7T9hg64 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3ILpsACgkQC3+MBN1Mb4jaBQCg1MqHxXR0V1xJBvw3N4O4VMRX XqsAn22odtOfnb5vv148fvN+bxC5WnzF =yvE7 -----END PGP SIGNATURE----- --sF4+LqaTi7T9hg64--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110509181243.GI48734>