Date: Tue, 24 Nov 1998 00:52:18 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bob Bishop <rb@gid.co.uk> Cc: Luoqi Chen <luoqi@watermarkgroup.com>, cnielsen@pobox.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel threads Message-ID: <199811240852.AAA13083@apollo.backplane.com> References: <Pine.BSF.3.96.981124073839.13356A-100000@seagoon>
next in thread | previous in thread | raw e-mail | index | archive | help
:Hi,
:
:On Mon, 23 Nov 1998, Matthew Dillon wrote:
:
:> What we really need to do is integrate the VFS layer abstraction into
:> the buffer cache and get rid of all the baggage in the buffer pointer
:> (bp) layer. [etc]
:
:What does this do to the minimum kernel footprint (think picobsd etc)?
Well, with the scheme I outlined it's a straight percentage, so the
minimum footprint scales to the amount of memory in the machine. You
could also reduce the number of cache entries you preallocate,
but the minimum there is going to come in at around 1x the number of
pages in the system (plus enough to handle active I/O) - considerably
fewer then the 4x recommended. It would work, you would simply be
trading off cpu for memory as it would take more cpu to resolve cache
misses.
Still, there is a huge amount of memory savings to be had in other areas.
I just don't know how feasible it all is... it would mean a huge amount of
rewriting. If we add this sort of cache in, we'd definitely want to get rid
of the buffer pointer code. Since the BP code combines vnode block mapping
for I/O and managed KVM buffers (abstracting files into linear segments of
KVM for device operation and block resizing purposes), the only way I can
think of to remove it would require going to the direct-physical-map scheme
and rewriting all the devices to use it. For example, UFS could still have
an 8K filesystem block size but the indexing code would have to operate
through the hardware page size'd buffer cache. The disadvantage of this
scheme is that it limits main memory to around 2GB on a 32 bit machine.
The list of advantages goes on forever, though... everything I outlined in
previous messages plus even more. Although a lot of rewriting would have
to be done, the end result would be a much smaller kernel due to the
huge amounts of code that I think could be removed. BP's go away, kernel
page table manipulation and related special casing dissolves away leaving
only a few managed areas (w/ preallocated page tables) to handle supervisor
stacks. Direct access to UVM goes away, removing all the special casing
related to that and cleaning up UIO considerably (instead, the kernel code
accesses UVM directly through the new buffer cache). Most of the MMU
complexity disappears. Virtually every part of the kernel would be
simplified. Interrupts could even be moved into kernel threads without
adding much (or any) overhead, which reduces the size of the per-process
supervisor stack considerably. Async device I/O would become trivial -
e.g. read() -> internal_read(curprc->p_UVMVNode, uptr, bytes) with devices
accessing UVM through the buffer cache rather then directly, which also
makes it trivial to move async operations into kernel threads.
The benefits cascade very quickly.... if one is willing to give up > 2GB
memory configurations on 32 bit cpus.
-Matt
:--
:Bob Bishop +44 118 977 4017
:rb@gid.co.uk fax +44 118 989 4254
:
:
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811240852.AAA13083>