Date: Sat, 20 Feb 1999 02:15:22 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert@primenet.com> Cc: julian@whistle.com (Julian Elischer), andre.albsmeier@mchp.siemens.de, sanewo@ba2.so-net.ne.jp, freebsd-hackers@FreeBSD.ORG Subject: Re: softupdate panic, anyone seen this? Message-ID: <199902201015.CAA07195@apollo.backplane.com> References: <199902192352.QAA11969@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> WHY would you async mount an MFS?
:> it's an MFS!
:
:So you don't have to stall the caller copying the page-off-vnode
:memory to the swappable-page memory.
:
: Terry Lambert
: terry@lambert.org
So you don't have to do a context switch for each individual strategy
call.
--
Progress is being made on a number of fronts. I have about 9 commits
ready to go as soon as they are approved which fix a bunch of things,
including the VN device. And I have two patches that 'appear' to fix
softupdates that have been sent to the softupdates crew for fodder.
With them, I no longer get lockups or panics on a softupdates-enabled UFS
filesystem sitting on a NFS-file-backed VN partition. ( But I've no idea
if I'm solving the problems the right way. Probably not :-) ).
I can now reliably make buildworld on the above said VN configuration
( as /usr/obj ). It's sweet, too... softupdates does an incredible
job balancing the network load. It doles the file writes out to
the network so smoothly I at first didn't realize that it was working.
MFS, in contrast, eats system memory until the pageout daemon is forced
to start paging it to swap in weird-looking bursts. The network I/O
doesn't get in the way of the build at all - the system is 0% idle through
most of it.
I think the ultimate 'mfs' is going to be a direct-swap-backed VN partition
running a softupdates-enabled UFS. The beast doesn't exist yet, but it
wouldn't be too hard - we'd just use a vm_object instead of a vnode and
vm_pager_get/put_pages().
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199902201015.CAA07195>