From owner-freebsd-net Fri Nov 30 11:31: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 8491737B416 for ; Fri, 30 Nov 2001 11:31:00 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fAUJQeQ32024; Fri, 30 Nov 2001 11:26:40 -0800 (PST) (envelope-from rizzo) Date: Fri, 30 Nov 2001 11:26:40 -0800 From: Luigi Rizzo To: Bruce Evans Cc: net@FreeBSD.ORG Subject: Re: Revised polling code for STABLE Message-ID: <20011130112640.I30981@iguana.aciri.org> References: <20011130084421.A30672@iguana.aciri.org> <20011201042322.O2240-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011201042322.O2240-100000@gamplex.bde.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Dec 01, 2001 at 05:30:14AM +1100, Bruce Evans wrote: > But this doesn't require _very_ accurate syncing with the hardclock > interrupt. It's similar to scheduling. The scheduler runs approximately Maybe there is a misunderstanding here. What i want to call from hardclock() is the threshold adjustment, not ether_poll(). ether_poll() is scheduled as a soft interrupt, and I do want it to have priority over other soft interrupts for reasons that i tried to explain. Re. the threshold adjustment, the fact is that i am working on much finer timescales than the seconds you mention for the scheduler. And, especially, i want to detect that i am overloading the system as soon as possible, that is at the first available clock interrupt. > > well the code i am adding is really short, look at the patch! > > It boils down to reading one variable and updating poll_burst > > accordingly. > > Sorry, I deleted the patch. Everything that writes the variable > would need locking or something to give atomic accesses. I don't > remember where it is written. You see, this is one of the problems i am having with this code review! I get regularly summoned on what my code is supposed to do or not to do, even when I am doing something very close or exactly like what is being suggested. Sure that happens because the patch touches many files, and so one is tempted (with the genuine intention to help) to give generic suggestions as opposed to look at the actual details of the code. But this is not good for the project. The poster has the impression that there is something wrong with the code, the author feels mistreated, and then it takes a fair bit of energy, time and email exchange to clarify the issues, and more often than not things stall because one gives up, or sometimes in the discussion people (including myself) get upset because they take things as a personal critique (which i am sure is nowhere near anyone intentions, but we are human...). In this case, apart from the critique on keeping the code short (which is already) you mention locking (which i do not do). Do i need to lock variables ? I really don't think so. I said a number of times that this code is not supposed to run with SMP. If you specify both ETHER_POLL and SMP kernel options, the compiler will spit out an error message saying they are incompatible. So nothing that i can think of can cause consistency problems on the specific variables i am using. > With polling from timeout routines, doubling HZ would reduce the average > latency to below that for polling from hardclock() or soon after. I > think you need to increase HZ anyway, so increasing it even more would > be acceptable. But you want the _worst-case_ latency to be not much > larger than 1/(original HZ). See above about different polling in I do not really follow. Original latency (with interrupts) is unrelated to HZ, it's just the interrupt dispatch time plus delays from higher priority handlers being run. Yes I am raising HZ with polling, but the latency might still be higher than in the interrupt-based system. > > I have considered adding another interrupt class (as a matter of fact, > > i even did that) with higher priority than other SWI, but i thought > > it was overkill because splsoftnet(NETISR_POLL) still seems to be > > the highest priority soft interrupt and the change is less intrusive. > > Am I wrong on this ? > > A little. splsoftty() is higher. Also, polling might be useful for > non-net drivers. next step... i cannot do all at once! cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message