From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <487F5216.7070905@gmx.de>
Date: Thu, 17 Jul 2008 16:07:18 +0200
From: Kernel Panic <cinap_lenrek@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <487EFBC8.4060607@gmx.de>	<2125ed224c77c85fc13d81eb95377a2a@terzarima.net>
	<9f3897940807170632t12dd5deej23608689137b1a64@mail.gmail.com>
In-Reply-To: <9f3897940807170632t12dd5deej23608689137b1a64@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] 8 cores
Topicbox-Message-UUID: ea92667c-ead3-11e9-9d60-3106f5b1d025

Paweł Lasek wrote:
> A much more important reason might be the fact that memory mapping of
> files is only one function of mmap() and company. Basically when you
> have mmap() and munmap() you can write your own allocator (which might
> be very useful, especially for databases). I won't delve into using it
> for I/O, but a specialized memory allocator can get you a big speedup
> - after all application developer knows the memory usage pattern of
> his app better than kernel/system library.
>
you can write you own allocator with brk() or
segattach()/segbrk()/segfree() too... the
only things you cant is:

- map on some fixed address
- remap

cinap