From owner-freebsd-hackers  Tue Sep 24 09:45:32 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA22506
          for hackers-outgoing; Tue, 24 Sep 1996 09:45:32 -0700 (PDT)
Received: from critter.tfs.com ([140.145.230.177])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA22428;
          Tue, 24 Sep 1996 09:45:16 -0700 (PDT)
Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id RAA00306; Tue, 24 Sep 1996 17:21:27 +0200 (MET DST)
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
cc: hackers@FreeBSD.ORG, bde@FreeBSD.ORG, asami@FreeBSD.ORG
Subject: Re: Optimizing bzero() 
In-reply-to: Your message of "Tue, 24 Sep 1996 09:38:24 +0200."
             <199609240738.JAA00165@labinfo.iet.unipi.it> 
Date: Tue, 24 Sep 1996 17:21:26 +0200
Message-ID: <304.843578486@critter.tfs.com>
From: Poul-Henning Kamp <phk@critter.tfs.com>
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


Luigi,

The problem really is that you need a couple of parameters more to malloc:

	void *
	my_wish_malloc( int bytes,
			int flags,
			int *length)

	bytes is the number of bytes you want.
	flags can be used to specify various options:
		ZERO -- please clean it for me.
		EXTEND -- I may ask you for more later
	in *length malloc will tell you how much you actually got
	ie you malloc(129) and it will tell you 256 bytes are there for you.

Next you need a indirect version:

	void *
	my_wish_imalloc( int bytes
			void **ptr,
			int flags
			int *length);

Same as above, except that the only pointer the program uses to access
the memory is *ptr, thus malloc can realloc the memory without telling
the process merely by updating *ptr to point to the new place.

Now you can start to optimize things, but as long as we cannot talk
more efficiently with malloc, it's not really much use to change the
behaviour.  If we had this kind of interface, it would be a sensible
thing for malloc to do to send pages to the kernel-idle-washer for
cleaning, but with the interface has been cast in iron by POSIX: forget it.

The next thing you could start to consider is when people realloc a
multipage allocation to something bigger, it would be nice to be able
to ask the kernel to "move these pages to this address" and then extend
It there instead of copying the contents.

and so on...

Fortunately, I can promise you that we are squarely up against the
wall of diminishing return here:  Just the madvise case happens a lot
less than you would think.  (Do you have access to a PostScript printer
with a good resolution ? A4@600dpi or better ?  I can send you some
files that will show you what I mean).

BTW: I have still not decided if the madvise should use _FREE or _DONTNEED
yet, it must depend on experience.

Finally, if you really want to get something done, make stdio use mmap
instead of read on regular files...  You save a page per FILE * you 
open and a bcopy of the contents of the file...   I know writes are
tricky, so just do it for read-only FILE *'s initially.
	
--
Poul-Henning Kamp           | phk@FreeBSD.ORG       FreeBSD Core-team.
http://www.freebsd.org/~phk | phk@login.dknet.dk    Private mailbox.
whois: [PHK]                | phk@ref.tfs.com       TRW Financial Systems, Inc.
Future will arrive by its own means, progress not so.