Date: Mon, 15 Feb 1999 23:48:09 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "John S. Dyson" <dyson@iquest.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) Message-ID: <199902160748.XAA21828@apollo.backplane.com> References: <199902152207.RAA01900@y.dyson.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:Are you blocking on excessively large numbers of output requests? You
:know *exactly* the issue at hand, and it has to do with the backpressure
:needed to keep the pageout daemon from doing an evil nasty on all of the
:pages in the system.
:
:The original version of your code appeared to have the problem, and if
:you have fixed it, or you aren't queueing more than a few pageouts at
:a time (perhaps <10 or so), then you are okay. Note that "pageouts"
:often imply the need for "pageins", and often the same disk for "pageouts"
Excuse me, John, you aren't listening.
The ORIGINAL VM CODE. Do I need to repeat that? The *ORIGINAL* VM CODE
does not have one single line of source to prevent excessive queueing
of I/O for pageout ops.
The *NEW* VM CODE does not change this unless you are talking about the
getpbuf() code changes, which is nothing more then safety valve to prevent
any single subsystem from eating *all* available pbuf's in order to prevent
the memory interlock that can occur with that case.
I've repeated this three times to you so far.
It's fallen on deaf ears three times now.
You keep on accusing me of doing something wrong. I keep on telling you
that I haven't done what you seem to think I have done. If you are going
to continue to accuse me, then point to the code that you feel is broken.
-Matt
Matthew Dillon
<dillon@backplane.com>
:John | Never try to teach a pig to sing,
:dyson@iquest.net | it makes one look stupid
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?199902160748.XAA21828>