Date: Thu, 22 Mar 2012 17:13:35 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Eric Saint-Etienne <eric.saintetienne@gmail.com>, Ryan Stone <rysto32@gmail.com> Subject: Re: malloc pages map to user space Message-ID: <201203221713.35202.jhb@freebsd.org> In-Reply-To: <CACJX%2B511wZyKVXeYqUQ3v6Uh0ZN83TbBZT7CC6V6N0jTsibD-w@mail.gmail.com> References: <CACJX%2B52DPPYea5k6QxQ6WQ62GEA9YHGr4y=ETUpPArNL83kh5w@mail.gmail.com> <CAFMmRNxvLz9G73Kn2BXq9WG5-0ZcTN%2BSumawWDzz5DRj=hN4PQ@mail.gmail.com> <CACJX%2B511wZyKVXeYqUQ3v6Uh0ZN83TbBZT7CC6V6N0jTsibD-w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, March 22, 2012 3:57:11 pm Eric Saint-Etienne wrote: > > If your kernel module creates a device in /dev that implements the > > mmap method, then you don't need to worry about mucking around with > > vm_maps and objects and whatnot. Your mmap method just needs to be > > able to convert offsets into the device into physical memory > > addresses, > > Yes I'm aware of this facility, thank you. > > > and the vm infrastructure will do the rest for you. > > Since this mapping is on the main path of the driver, I'm worried that > the overhead on each access of a page fault and a function call (the > pager associated with a cdev mmap) is too much to bear. It only does this on the first page fault though, not every access to the page. This can be a bit of a downfall as well as you can't easily invalidate a mapping once you've established it. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203221713.35202.jhb>