From owner-freebsd-hackers Tue Sep 24 20:44:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA10815 for hackers-outgoing; Tue, 24 Sep 1996 20:44:29 -0700 (PDT) Received: from hp.com (hp.com [15.255.152.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA10773; Tue, 24 Sep 1996 20:44:24 -0700 (PDT) Received: from fakir.india.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA002961183; Tue, 24 Sep 1996 20:13:10 -0700 Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA109333032; Wed, 25 Sep 1996 08:43:52 +0500 Message-Id: <199609250343.AA109333032@fakir.india.hp.com> To: Poul-Henning Kamp Cc: Luigi Rizzo , hackers@freebsd.org, bde@freebsd.org, asami@freebsd.org Subject: Re: Optimizing bzero() In-Reply-To: Your message of "Tue, 24 Sep 1996 17:21:26 +0200." <304.843578486@critter.tfs.com> Date: Wed, 25 Sep 1996 08:43:52 +0500 From: A JOSEPH KOSHY Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>> "phk" == "Poul-Henning Kamp" writes phk> The next thing you could start to consider is when people realloc a phk> multipage allocation to something bigger, it would be nice to be able phk> to ask the kernel to "move these pages to this address" and then extend phk> It there instead of copying the contents. Makes sense; can this be done without major surgery though? How costly would it be for malloc(3) to invoke a system call to re-arrange the address space compared to an memory allocation followed by a bcopy()? phk> Finally, if you really want to get something done, make stdio use mmap phk> instead of read on regular files... You save a page per FILE * you phk> open and a bcopy of the contents of the file... I know writes are phk> tricky, so just do it for read-only FILE *'s initially. If we are at this, why not move to an SFIO like framework? SFIO did support STDIO in backward compatibility mode and in addition supported `layering' functionality into the stream; for example; you can `push' a compression or de-compression layer onto an open FD. Its was also supposed to be signal-safe. I believe the initial implementation of SFIO that was described in the USENIX paper did use `mmap' and reported a healthy speed up for basic file operations. Koshy