Losing pages from a mmap in threaded app vs. non-threaded
eischen at vigrid.com
Wed Nov 19 13:24:48 PST 2003
On Wed, 19 Nov 2003, Sean McNeil wrote:
> Hello all,
> I have an interesting problem. I've ported a device driver to FreeBSD
> from Linux and all works just fine with the non-threaded application.
> When I use threads, the first 8 pages of the map get removed from the
> process vmspace.
> A trick is used to mmap different memory pools of the driver. There are
> 3 of them and an offset is given to mmap to identify which one:
> The buffer I see losing the first 8 pages is the one mmap'd with
> I haven't looked into the other mmaps, as the above one is the most
> important. mmap is called correctly and each page is returned
> appropriately. Again, this works without threads.
> Is there some mmap region that threads uses that is conflicting with my
> choice? Is there any known issue with mmap and threads? This problem
> happens with libc_r.so, libkse.so, and libthr.so.
> The work I'm doing is split into driver/application and turnaround is
> high to get the application people to recompile with different values
> (in progress), so I thought asking here might answer my question sooner
> than experimentation.
> All comments/replies are greatly appreciated,
The thread libraries use mmap to map kern.usrstack as
thread stacks and guard pages. I don't know how this
would affect your driver.
More information about the freebsd-threads