Date: Wed, 19 Nov 2003 16:24:45 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Sean McNeil <sean@mcneil.com> Cc: freebsd-threads@freebsd.org Subject: Re: Losing pages from a mmap in threaded app vs. non-threaded Message-ID: <Pine.GSO.4.10.10311191623030.15552-100000@pcnet5.pcnet.com> In-Reply-To: <1069273626.93981.10.camel@blue.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > 0x10000000 > 0x20000000 > 0x40000000 > > The buffer I see losing the first 8 pages is the one mmap'd with > > 0x40000000 > > 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, > Sean 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. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10311191623030.15552-100000>