From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 17 Jul 2008 07:32:37 -0700
From: "Roman V. Shaposhnik" <rvs@sun.com>
In-reply-to: <13426df10807170555s746fa829p130970922058f692@mail.gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-id: <1216305157.4327.104.camel@goose.sun.com>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <487EFBC8.4060607@gmx.de>
	<2125ed224c77c85fc13d81eb95377a2a@terzarima.net>
	<13426df10807170555s746fa829p130970922058f692@mail.gmail.com>
Subject: Re: [9fans] 8 cores
Topicbox-Message-UUID: ea9ed2ae-ead3-11e9-9d60-3106f5b1d025

On Thu, 2008-07-17 at 05:55 -0700, ron minnich wrote:
> Looking at the Plan 9 exec path it's hard to see a reason that Plan 9
> could not do mmap, it just doesn't. But lots of code nowadays depends
> on mmap being there. Is there something I'm missing?

I've commented privately to Erik that this is, in fact, what I'm
interested in: using mmap() not as a first-class abstraction,
but as a useful optimization technique in places where it can
speed things up.

Thanks,
Roman.

P.S. Of course, as was pointed out
   (a) speeding things up in one place (read/write) could easily
       slow them down elsewhere in the kernel
   (b) there's no point in lots of RPMs if 99% you're in neutral
and (a) is precisely why I tend to ask question instead
of implementing this stuff up -- I'm just not all that much
of an OS kernel guy to be 100% sure that it will end up
being worth it.