Date: Thu, 20 Jun 2002 23:42:30 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Bosko Milekic <bmilekic@unixdaemons.com>, Gary Thorpe <gat7634@hotmail.com>, freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <Pine.BSF.4.21.0206202333160.34612-100000@InterJet.elischer.org> In-Reply-To: <3D12A886.425D8231@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
terry.... you know mate, it would be a Good Thing (tm) if you got back int ocoding... and I don;t mean codimg for that box in you apartment, but coding so as to provide distinct reviewable patches for FreeBSD or the topics you are interested in.. I know your excuses include: 1/ your machines are not running -current 2/ you are coding on an incompatible set of patches at teh moment 3/ you, like the rest of us have time constraints with work etc. but: could you tone down teh lectures a bit until you can actually start doing things to help with the load? At least BDE is starting to commit things again which makes it a much less annoying event to get a 'comentary' on one's style bugs when one commits, because one knows the author is actually committing things himself these days. (hopefully even more(!)) but you have not submitted code for so long that it makes what you say less 'compelling'. If YOU were to come up with a set of 'swith-on'able (and switch-offable) set of patches on any of the topics you find yourself discoursing on, I'm sure that everyone would be thrilled to give them a try. s'nuff.. ok get to the coding wheel.. On Thu, 20 Jun 2002, Terry Lambert wrote: > Bosko Milekic wrote: > > On Thu, Jun 20, 2002 at 08:47:24PM -0700, Terry Lambert wrote: > > [...] > > > I do, though, have lots of papers on receiver livelock that I've > > > posted the references to before. The problem there is that most > > > people don't read papers. > > > > I think that more of the problem is that some people do read papers > > and, what's more, understand them; however, what these people are > > actually looking for is not more references to papers, but > > implementation of the concepts presented in those papers for FreeBSD, > > proving that those concepts also apply to _our_ system. > > Well, I've suggested the porting of the old LRP (non-RESCON) > code to FreeBSD already, as a project. > > If you are willing to run 4.0 or 4.3, there are implementations > of the LRP code for both, from Rice University and Duke University. > Their licenses are unfortunately anti-commercial, requiring that > the user contact the Rice University Office of Technology Transfer, > unless you are doing a port of the FreeBSD 2.2 implementation. > > If you just want the concept proven, and are willing to run with > FreeBSD 4.3, then I would suggest the Duke University code, which > I believe proves the concept of LRP nicely. > > > > Certain approaches work well with others, and different approaches may > > work less well. I'm not claiming that your suggestions are bad, I'm > > just stating that they shouldn't be taken as being totally correct for > > us as we cannot adequately evaluate them right now [*]. > > Here is the FreeBSD 4.3 LRP-RESCON code: > > http://www.cs.duke.edu/~anderson/freebsd/rescon/ > > > > > However, you did initially mention that it would be good to see some > > sort of evaluation happen, and so perhaps I just misunderstood you and > > wrongly interpreted you once you started to make claims that seemed to > > suggest (to me) without a doubt that your solution is THE best one. > > Well, it is. 8-). > > Actually, I forward-ported the LRP code from Rice FreeBSD 2.2 to > FreeBSD 4.4 for a previous employer, and benchmarked it. > > Unfortunately, the code is unlikely to ever see the light of day, > like some of the work Jon Lemon has done for Cisco. 8-(. However, > I can say it benchmarked out at significantly better performance > than the non-LRP FreeBSD stack. Under oppressive load, the overall > system was around a factor of 4 faster on connections per second, > which, even given the integration of the SYN cache code, is probably > significant, since that code runs at NETISR. > > > > If that is indeed the case, then I appologize. I maintain the "GEB" > > is a book worth reading, though. :-) > > It's a good book. I got my copy a very long time ago (1981); I also > recommend "The Mind's I" and "The Emperor's New Mind". 8-). > > > > [*] In fact, > > Chuck just posted in response to this thread and made some very good > > points regarding performance, and how we may find that the optimal > > solution is different for different SMP configurations. > > I saw that. I need to think some of them over. I think I have a > fix for the migration issue he references. It's solves the problem > by avoiding locking unless there's actual migration going on. The > migration policy is a seperate issue, and can be dealt with totally > seperately. I'd suggest starting with a simple two handed clock > algorithm, and getting more complicated after seeing what that does. > > I'll probably have more to say after I've slept on his posting. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > 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?Pine.BSF.4.21.0206202333160.34612-100000>