Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Nov 2001 11:26:40 -0800
From:      Luigi Rizzo <rizzo@aciri.org>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        net@FreeBSD.ORG
Subject:   Re: Revised polling code for STABLE
Message-ID:  <20011130112640.I30981@iguana.aciri.org>
In-Reply-To: <20011201042322.O2240-100000@gamplex.bde.org>
References:  <20011130084421.A30672@iguana.aciri.org> <20011201042322.O2240-100000@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011130112640.I30981>