Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 02 Jan 2001 12:06:56 -0800 (PST)
From:      John Baldwin <john@baldwin.cx>
To:        alpha@FreeBSD.org
Subject:   Disabling ints via IPL
Message-ID:  <XFMail.010102120656.john@baldwin.cx>
Resent-Message-ID: <200101022006.f02K6WG01731@meow.osd.bsdi.com>

next in thread | raw e-mail | index | archive | help
Part V: this has a bit more meat in the explanation..

On 17-Nov-00 Andrew Gallatin wrote:
> 
> John Baldwin writes:
>  > Ugh.  Yuck.  Hmm.  We need that ast() so that we switch to the interrupt
>  > thread, too (we will need it for light-weight ithreads as well).  We
> should
>  > probably lower the IPL to the saved IPL in the stack frame instead.  It
> will
>  > always be zero except for this hack for pc164's (since this is only done
> when
>  > returning to userland, which runs at IPL 0).  Hmm.  Actually, we will want
> to
>  > restore the saved IPL in the frame to 0 after this inside of ast() (since
> ast()
>  > is going to switch to the itnerrupt thread, and we will be back at IPL 0
> when
>  > we return).  So, what we really need to modify is not the IPL we switch to
> on
>  > return, but the IPL we use here before calling ast().
> 
> That should make things a little easier.
> 
> I'm still trying to understand what's going on here... What happens if
> the interrupt thread blocks?  Does a context switch happen and the
> next process continue to run on the interrupt stack until such time as
> the original interrupt thread runs to completion?

No, the interrupt thread has its own stack (it is a kernel process), so the
next process continues to run in its own context.  The raised IPL will be
propagated via sched_lock, however, and will stay raised until it is lowered
via ithd_loop().  The assumption is that your userland process is not going to
resume until after this has happened (otherwise the IPL would drop down again
and *boom*).  This assumption should be safe because interrupt threads have a
very high priority, and if an ithread blocks on a mutex, its priority will be
propagated (once that code works :-P) to the process holding the mutex.  That
process will be in the kernel, so it won't be the userland process we just
interrupted.  Hmm, if we get an interrupt in the kernel though we need to
modify the saved IPL in the frame.  Ugh, ok.  Then go back to the original
proposal (modify the IPL in the frame).  In the ast() case in exception_return,
we swap IPL_0 (we know 0 is ok, because we were interrupted from userland) with
the saved IPL in the stack frame, and then set the IPL to the one we just got
out of the saved stack frame.  Since ithreads only block for SMP, and due to
priority propagation and the high priority of ithreads, the userland process
won't run again until the ithread has completed and run.  We will only be
running processes that are in the kernel.  Once a process in the kernel
releases the mutex that the ithread is blocked on, it will resume its normal
priority, and the ithread will run immediately (since the ithread has higher
priority), dropping the IPL back down.  The process in the kernel won't return 
to userland without dropping the lock, so userland won't ever be running at an
IPL other than 0.  Note that ithreads will only block and priority propagation
only needs to work in the SMP case.  The only way an ithread will block in the
UP case is if the interrupted process is in the kernel, and it will run next
(since it is the second highest priority since it was just chosen to run last)
and eventually release the lock enabling the ithread to run and lower the IPL. 

whew..

> Drew

-- 

As a side note, if IPL is across all CPU's, then on an SMP machine, it might be
possible that while one CPU is running the interrupt handler, another CPU will
be running a userland process at a raised IPL, but I don't think there is
anythign we can do about that, and I don't think it will hurt us since the only
thing that really cares about/is affected by the IPL is the kernel.

-- 

John Baldwin <john@baldwin.cx> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


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?XFMail.010102120656.john>