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