Date: Sat, 6 Nov 2004 13:06:06 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Julian Elischer <julian@elischer.org> Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/sys buf.h Message-ID: <20041106130606.60f3dea3@Magellan.Leidinger.net> In-Reply-To: <418BD796.3040706@elischer.org> References: <40541.1099561211@critter.freebsd.dk> <1099650992.418b57b01c33b@netchild.homeip.net> <418BD796.3040706@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 05 Nov 2004 11:42:14 -0800
Julian Elischer <julian@elischer.org> wrote:
[buf-junta work]
> >Do you have an outline where this heads to and why?
> >
>
> when systems were smaller the number of cached bufs was small, and bufs
> represented 'buffers' likely to used soon fo rIO and IO requests were
> simple,
> it made sence to combine the IO request and the storage descriptor (buf).
>
> Since then, storage is done via the vm system, IO requests have gotten
> bigger,
> and the number of IO requests needed at any time has remained small. it
> makes less
> sense to have an IO request with every buf storage descriptor.
You haven't said it explicitly, but I assume there are cases where an IO
request doesn't need a buf storage descriptor. Is this correct?
I was asking for something like an annotated roadmap. Something like
"After X will be done, we need to look at Y, X is an infrastructure
change for Y and we want Y because it allows us to do Z." This would
allow those who are reading cvs-all to see where we are standing and
where we are heading (and to applaud when we reach milestones).
Bye,
Alexander.
--
The best things in life are free, but the
expensive ones are still worth a look.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041106130606.60f3dea3>