From owner-freebsd-threads@FreeBSD.ORG Wed Nov 19 13:26:27 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B75B916A4CE for ; Wed, 19 Nov 2003 13:26:27 -0800 (PST) Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92D7143FAF for ; Wed, 19 Nov 2003 13:26:21 -0800 (PST) (envelope-from sean@mcneil.com) Received: from blue.mcneil.com (cpe-66-75-176-109.socal.rr.com [66.75.176.109])hAJLQAcX020089; Wed, 19 Nov 2003 13:26:10 -0800 (PST) Received: from [66.75.176.109] (mcneil.com [66.75.176.109]) by blue.mcneil.com (8.12.10/8.12.10) with ESMTP id hAJLQAUe004056; Wed, 19 Nov 2003 13:26:10 -0800 (PST) (envelope-from sean@mcneil.com) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Organization: Sean McNeil Consulting Message-Id: <1069277169.4052.0.camel@blue.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 19 Nov 2003 13:26:10 -0800 Content-Transfer-Encoding: 7bit X-DCC-dmv.com-Metrics: blue.mcneil.com 1181; Body=2 Fuz1=2 Fuz2=2 cc: freebsd-threads@freebsd.org Subject: Re: Losing pages from a mmap in threaded app vs. non-threaded X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2003 21:26:27 -0000 OK, would this happen to be 8 pages typically? On Wed, 2003-11-19 at 13:24, Daniel Eischen wrote: > 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.