Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Jan 2001 12:23:58 -0800 (PST)
From:      Matthew Jacob <mjacob@feral.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        alpha@FreeBSD.org, Doug Rabson <dfr@nlsystems.com>
Subject:   RE: Interrupt threads
Message-ID:  <Pine.LNX.4.21.0101021218440.14503-100000@zeppo.feral.com>
In-Reply-To: <XFMail.010102121609.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> > 2. Giant is like any other mutex in this context- whoever holds Giant should
> > be resumed if an ithread hits Giant. As soon as they drop Giant there should
> > be an immediate cpu_switch which had better resume the [ one of the ]
> > ithread[s] that had been blocked.
> 
> Since ithreads are a higher priority than any other process (they are in their
> own separate run queue for goodness sake) this is already true..

yes, yes, just checking..

>  
> > 3. You should not have to do anything with a trapframe until you actually are
> > returning from an interrupt. You can't assume that a 'return from interrupt'
> > can return with IPL set to non-zero. This is such a POLA violation that I
> > wouldn't expect it to work much of anywhere. Basically, you should take an
> > interrupt and immediately have the ithread for it run (unless fast- and until
> > we can get this right, only allow one non-fast interrupt at a time for
> > alpha). If this ithread hits a lock and can't get it, the holder of that lock
> > (whether Giant, Fred, Foo, Bar) gets resumed until it drops that lock,
> > whereupon the ithread should be resumed. This can repeat until the ithread is
> > done, whereupon a real return from interrupt can occur.
> 
> For nested interrupts (clock interrupt during a normal interrupt for example)
> the IPL can _already_ be non-zero in the trapframe.  However, the lock
> contention you describe already holds true because ithreads have such a high
> priority.

Clock on alpha is something of an oddity- it comes in not as an interrupt but
as a separate vector.

>...
> 
> The light weight ithreads will make performance slightly better, but they won't
> solve this problem.  When an ithread blocks on a mutex, you still have the
> problem of switching to another process and running it while still needing to
> disable the interrupt.  That we won't ever get away from.

You switch to the process w/o changing IPL. It is resumed at the IPL of the
ithread that blocked. In the software way of looking at it, it inherits the
priority of the ithread until it releases the lock that caused it to be
resumed.

> 
> > 4. What defeated me immediately upon looking at Doug's stuff is all of the
> > thread pri seems to be a software construct, so has no real hardware
> > linkage. Additionally, I did not take the time to try and find an easy way to
> > find and reschdule the proc that holds a lock if I'm trying to acquire it
> > from
> > an ithread and am blocking. Seems to be a bit of work there.
> 
> Yes, you can't tie the IPL to a thread.  The IPL is tied to two events:
> 
> 1) An interrupt trigger raises the IPL
> 2) Handling the interrupt lowers the IPL back to where it was.
> 
> Since 2) is now asynchronous with respect to 1) sort of, we have to be a bit
> more tricky with when we lower the IPL rather than letting the machine do it
> for us.

This is where we disagree. You must tie the IPL to a thread if you cannot
disable interrupts. I

Look- this arguments is a waste of time. When actually works, we'll see what's
what.

-matt




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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0101021218440.14503-100000>