Date: Wed, 25 Sep 1996 08:43:52 +0500 From: A JOSEPH KOSHY <koshy@india.hp.com> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, hackers@freebsd.org, bde@freebsd.org, asami@freebsd.org Subject: Re: Optimizing bzero() Message-ID: <199609250343.AA109333032@fakir.india.hp.com> In-Reply-To: Your message of "Tue, 24 Sep 1996 17:21:26 %2B0200." <304.843578486@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>> "phk" == "Poul-Henning Kamp" <phk@critter.tfs.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609250343.AA109333032>