Date: Wed, 6 Dec 2000 03:14:18 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bmilekic@technokratis.com (Bosko Milekic) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG Subject: Re: zero copy code review Message-ID: <200012060314.UAA24462@usr05.primenet.com> In-Reply-To: <Pine.BSF.4.21.0012051623180.9538-100000@jehovah.technokratis.com> from "Bosko Milekic" at Dec 05, 2000 04:34:30 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> I don't understand what you're complaining about already. Just set > kern.ipc.mbuf_wait to 0 and you'll have the behavior you're looking for. I am looking for semantics, not behaviour. The difference is the cost that I end up paying. > As for the kernel, people must always keep checking whether their mbuf > pointer is NULL following any type of allocation and deal with it > appropriately (return ENOBUFS or drop the packet) until a real preventive > global preventive measure is put into place (think vm_state a-la PHK, or > something similar). This otherwise unnecessary checking is what I'm complaining about. I don't like it in my code path, it slows things down unnecessarily. > Changing the behavior of M_WAIT to not return NULL ever is out of the > question. You mean "changing it back", of course... > I don't need to explain myself again. If you want to test this > theory, try lowering NMBCLUSTERS (so it's easy to exhaust mb_map), > heavily load your network (from the outside) and tune your > kern.ipc.mbuf_wait accordingly, so that `netstat -m' shows a "requests > for memory delayed" > "requests for memory denied." This should give you > an about optimal wait time for heavy network load. This is your "normal > wait time." I see you attempting to tune a pool entry rate in order to deal with a pool retention time for something that I don't think should be in a hysteretical loop in the first place. > Now load your system with some local DoS (allocate very large > socket buffers in a tight loop, for example) and watch your system > effectively deadlock, and then see how much you're glad that your process > isn't hanging in the kernel indefinetely and how ^C eventually does its > job and kills the process. Then watch your system recover. I guess you are talking about interupting the DOS program, and not some victim program here, right? I think that this is a really artificial test case. I think a real test case would be to start the DOS program (nb: I don't let shell users on my servers anyway), and then start a different (victim) program, and watch what happens to the different program. I can ^C the victim program, in your scenario, but my system will fail to recover, and will remain unusable. My system really needs to set working set limitations on how many resources a single process is permitted to monopolize under low resource conditions. This would let my victim program continue to run, if sluggishly, and prevent a single DOS from doing more than slowing down my system. I think that you are maybe rendering the program interuptable the wrong way, and using the failure path on the allocation to back out the stack state leading up to the allocation attempt, as a convenience? > Just about the only thing that may be considered is changing the > name of M_WAIT to something more appropriate, if it means so much to the > majority of people (honestly, I would find even doing this a waste of > time, but if lots of folks think it's worth educating kernel developers > by changing the name of a flag, then we might as well). If the semantics don't revert back to their pre-timeout behaviour, I think it really would be best to have a meaningful name for it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200012060314.UAA24462>