Date: Mon, 15 Feb 1999 17:07:05 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) Message-ID: <199902152207.RAA01900@y.dyson.net> In-Reply-To: <199902152035.MAA19311@apollo.backplane.com> from Matthew Dillon at "Feb 15, 99 12:35:11 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon said: > : > :BTW, have you found/fixed the non-blocking swap pager problem yet. It seems > :that existing bugs should be fixed first. > > What non-blocking swap pager problem? this is the third time you've > brought this up, and the third time I've asked you to explain what > the frag you are talking about, and the the third time I have not > received any sort of explanation. > 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. I *have* told you about this before, and it falls on deaf ears. I love to argue with those people who like to create huge pending I/O queues that totally kill I/O latencies, and make a system perform terribly -- when they *think* that bandwidth is the issue. There are numerous issues associated with pending I/O requests, and the above is only two of them. Bandwidth is *sometimes* the issue, and tagged queueing helps alot of applications, but is of only limited (but some) use in paging. 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" is used for "pageins". Some kind of read-around-write strategy can help, but new disk I/O subsystems can absorb lots of transactions, further destroying latency. Allowing too few I/O requests (like 1 or 2) has it's own set of problems. Paging I/O is almost never bandwidth limited, it is almost always latency or wait on needed page or resource. On a timesharing system, with lots of processes, a hog process can easily push the pageout daemon to the point of freeing all pages. The key to the blocking has to do with giving the pagedaemon a rest, at the same time as keeping the I/O subsystem from being totally sandbagged with requests (further causing performance to fall into the abyss.) A large system will almost never be totally starved of memory, if you don't let the pageout daemon do it's dirty work into oblivion. I have said the above before, and now it is public. I hope that the competition doesn't see the above comments, because it will help them. The only reason why you get negative feedback from me (and others), is because you do not take advantage of tools available, and sometimes seem to believe that ego is a good replacement for collecting information, learning about the codebase that you are hacking, and simple courtesy in letting the original authors of the code keep you from making the same mistakes that they have. This courtesy extends to the userbase, who shouldn't be exposed to code that hasn't been reviewed. I have made mistakes in the past, and one thing that I didn't do, was to avoid asking for help. When someone was patient enough to work with me on the code, and to review it, I took advantage of it (and gave proper credit.) My ego doesn't support the short term buzz of committing code, but long term pain. One reason why I quit (amongst many) is that DG and I quit communicating (and I still don't know why), and I lost my reviewer/co-contributor. This put too much pressure on me over a year or so, and I know the reality of creating new works: collaboration is superior to cowboy behavior. The kernel itself, and VM code also needs a total rework. This isn't what is happening in the work that I have seen so far. There are upper level architectural considerations that have a body of knowlege residing in only a few people. *If* I am in that body of people, I possess only a small portion of those ideas, but I do try to communicate with, and learn from those who do know more than me. Again, this is the ego thing again, however, collaboration between *equals* or *near equals* works alot better than ramroding ideas, without communicating *effectively* with that body of knowledge. If you were effectively communicating with the existant body of knowledge, you would find alot less resistance to your changes. There are people with their livelihoods dependent on the FreeBSD codebase, and it should be treated with respect because of that. MAYBE you didn't know, but alot of communication happened behind the scenes regarding all of the FreeBSD VM and VFS code. Little such communication appears to be happening with you, and when it does, it is often one sided. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. 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?199902152207.RAA01900>