Date: Thu, 20 Jun 2002 21:16:06 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Gary Thorpe <gat7634@hotmail.com>, freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <3D12A886.425D8231@mindspring.com> References: <F112l4rhYQYx3G5aYY6000252ae@hotmail.com> <3D1293AE.FDEC441D@mindspring.com> <20020620230514.B38506@unixdaemons.com> <3D12A1CC.988B23D0@mindspring.com> <20020621000210.A48838@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D12A886.425D8231>