From owner-freebsd-arch Thu Jun 20 21:18: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 0BC2737B40A for ; Thu, 20 Jun 2002 21:17:00 -0700 (PDT) Received: from pool0544.cvx21-bradley.dialup.earthlink.net ([209.179.194.34] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17LFqp-00005q-00; Thu, 20 Jun 2002 21:16:47 -0700 Message-ID: <3D12A886.425D8231@mindspring.com> Date: Thu, 20 Jun 2002 21:16:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: Gary Thorpe , freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts References: <3D1293AE.FDEC441D@mindspring.com> <20020620230514.B38506@unixdaemons.com> <3D12A1CC.988B23D0@mindspring.com> <20020621000210.A48838@unixdaemons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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