Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Jul 2000 13:09:07 +0930
From:      Greg Lehey <grog@lemis.com>
To:        Warner Losh <imp@village.org>
Cc:        arch@FreeBSD.ORG, smp@FreeBSD.ORG
Subject:   Re: Tidying up the interrupt registration process
Message-ID:  <20000719130907.H12072@wantadilla.lemis.com>
In-Reply-To: <200007190323.VAA76910@harmony.village.org>
References:  <20000717163038.J26231@wantadilla.lemis.com> <200007190323.VAA76910@harmony.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 18 July 2000 at 21:23:23 -0600, Warner Losh wrote:
> In message <20000717163038.J26231@wantadilla.lemis.com> Greg Lehey writes:
>>  These flag bits are all lightly used, and there's confusing
>>  duplication of functionality.  For example, in nexus_setup_intr we
>>  have:
>>
>>  	case (INTR_TYPE_TTY | INTR_TYPE_FAST):
>>  		mask = &tty_imask;
>>  		icflags |= INTR_FAST;
>
> This code is wrong.  It should be moved out of the case statement.
> BDE posted a fix that I thought I'd committed, but it appears that I
> haven't done so yet.

I think this function needs to be completely rewritten in the course
of the implementation of interrupt threads.  It sort of works now, so
I don't think we should touch it further until the threads are up and
hobbling.

>>  In addition, these flags will have to change a lot in the change to
>>  threaded interrupts.  First, I intend to add two additional flags to
>>  struct intrec:
>>
>>  #define INTR_HEAVY	0x00000002	/* heavyweight interrupt process */
>>  #define INTR_LIGHT	0x00000004	/* light weight interrupt thread */
>>  #define INTR_THREADED   (INTR_LIGHT | INTR_HEAVY) /* any kind of interrupt thread */
>>
>>  This will allow us to let traditional interrupts, lightweight threads
>>  and heavyweight processes to coexist; when the change is complete, we
>>  may be able to let them go away.  The INTR_TYPE_TTY and friends are a
>>  different issue; at the moment I don't know if they're enough, but
>>  probably we should replace them with a process priority.  I'd be
>>  grateful for any thoughts on these subjects.
>
> The INTR_TYPE_TTY interrupts, except fast ones, are masked as a unit.
> Likewise with the INTR_TYPE_NET, etc.  The intent here is to provide
> assistance in serialization of access to crititical structures.  When
> you do a splnet, all the net devices who have an interrupt have their
> interrupt blocked.

Right, that's the current way things are done.  This will change too,
to be replaced by relative scheduling priorities.  That's the more
interesting question: how should they relate to each other?

>>  About fast interrupts, which currently seem to be used only by the sio
>>  driver: they perform their entire work before reenabling interrupts,
>>  and it's possible that we can keep them like that, though I haven't
>>  looked at the code yet.  Does anybody know any reason why we should
>>  convert them to threaded interrupts?
>
> Yes.  They are used by more than the sio driver.  I use them in at
> least two pci drivers that I have written for hardware that has
> extreme latency requirements that normal interrupts cannot
> accomplish.  This is the same sort of thing as the serial fifos.
> These have extremely hard requirements to be serviced in (on the order
> of micro seconds).  The "upper half" of the serial driver harvests the
> characters from the serial line when it gets interrupts and uses
> splsofttty() to activate the lower half of the driver.  These devices
> simply cannot tolerate scheduling delays at all, even very fast ones.

That's what I thought.  Does anybody else see a reason to convert fast
interrupts into threads?

> pci modems are an interesting problem.  You want to share an
> interrupt, but fast interrupts can't be shared.  On sufficiently
> fast machines, it isn't an issue, but on slow machines you can
> easily lose characters because interrupts are masked for too long.
> Heavy VM load (eg swapping) seems to make this problem happen more
> often than even just simple heavy disk I/O, but I've not done
> extensive tests to draw boundaries around this problem.

I can't see anything inherent in the treatment of fast interrupts
which says they can't be shared.  I'll take another look at the code;
maybe we can get rid of this restriction.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




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