Date: Tue, 7 Nov 2000 14:18:05 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: David Greenman <dg@root.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Bruce Evans <bde@zeta.org.au>, Kirk McKusick <mckusick@mckusick.com>, arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) Message-ID: <200011072218.eA7MI5w83049@earth.backplane.com> References: <200011072159.NAA00641@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok guys... I'll apologize here for tying these two things together. I
really thought Poul was talking about his idea in the context of an
extreme low-memory situation.
That said, however, I must still disagree with the concept. I think KVM
needs to be managed actively, not randomly from third party routine(s)
deciding they wants 'general' KVM subsystems to clear out some memory.
For example, take the vnode/inode cache ... the only subsystem that
really knows how to manage the vnode/inode cache is the vnode/inode
subsystem. If it doesn't know how to manage the cache, then certainly
no third party routine outside that subsystem which decides to call
the cleanup chain will know! Even if taken only as a hint, its a
hint given by a third party routine which has no clue about the
vnode/inode cache or any other cache. It's a worthless hint.
There is no such thing as 'potential breathing room' in an extreme
low-memory situation. There is only what you can guarentee, and the
only thing you can guarentee is managed control over the last
vm.v_free_reserved pages of memory. You guarentee the managed control
by guarenteeing that the only subsystems allowed to allocate from that
pool know how to release their resources in real time (allocate, perform
function, release) when faced with extreme low-memory situations.
The memhog3.c program, for example, can allocate and DIRTY *hundreds*
of megabytes in less then a second. Hundreds! No cleanup chain
could ever hope to compete against that.
Perhaps what we really need is some sort of wakeup chain,
something that runs once a second or 5 times a second or something like
that which could call a chain of management routines every so often
(rather then having to create kernel threads which sleep on lbolt for each
subsystem). These cleanup routines would be charged with the duty of
maintaining their respective caches, *not* flushing them, and would not
be allowed to block. Maintainance rather then flushing... I think
something like that could be beneficial.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011072218.eA7MI5w83049>