From owner-freebsd-hackers Wed May 17 23:25:29 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA26200 for hackers-outgoing; Wed, 17 May 1995 23:25:29 -0700 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA26193 for ; Wed, 17 May 1995 23:25:23 -0700 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id QAA24755 for freebsd-hackers@freebsd.org; Thu, 18 May 1995 16:02:53 +0930 From: Michael Smith Message-Id: <199505180632.QAA24755@genesis.atrad.adelaide.edu.au> Subject: mmap/madvise vs. open/write? To: freebsd-hackers@FreeBSD.org Date: Thu, 18 May 1995 16:02:53 +0930 (CST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1716 Sender: hackers-owner@FreeBSD.org Precedence: bulk I've been pestering Rod about things that he doesn't know about 8) and he suggested I should ask here (which is really fair enough...) > > I was reading the mmap manual pages the other day - how useful is > > madvise() from a performance point of view under FreeBSD? > > You would need to ask davidg@freebsd.org about that, you should probably > just ask on freebsd-hackers@freebsd.org. So I am... > > This I/O program is likely to mmap a file of a few tens of M (tops) and > > then copy into it, starting at one end and working to the other, > > which sounds like a prime candidate for MADV_SEQUENTIAL. > > Given that the vm system and the old buffer cache have been unified doing > an open() and read() calls actually does an mmap inside the kernel for > you. You may want to keep the code more portable by doing it this way, > and just know that the kernel is mmaping it for you on FreeBSD. Comments? Suggestions? > > Alternatively, I guess I can just malloc a huge slab, but I'd heard somewhere > > that the FreeBSD malloc was a bit picky about huge allocation requests, > > and mmap is sexier anyway 8) > > And with the new vm code the performance difference for mmap vs open/read > is almost nill now, infact it may even be faster to let the kernel do > the mmap, but I would have to defer to davidg on that one. > Rod Grimes rgrimes@gndrsh.aac.dev.com -- ]] Mike Smith, Software Engineer. msmith@atrad.adelaide.edu.au [[ ]] Genesis Software. genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control. (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" - Terry Lambert [[