[9fans] kenfs question?

[9fans] kenfs question?

[Venkatesh Srinivas]

Hi,

I was looking at the sources to kenfs and saw something that confused me -

ilock() (pc/lock.c) calls splhi() and then calls lock(). If that lock were contended,
how would the system not stop? And on a UP system, if you're inside an splhi() block,
why would you need to take an uncontended lock?

Thanks,
-- vs

Re: [9fans] kenfs question?

[erik quanstrom]

> ilock() (pc/lock.c) calls splhi() and then calls lock(). If that lock were contended,
> how would the system not stop? And on a UP system, if you're inside an splhi() block,
> why would you need to take an uncontended lock?

good question.  on a up system, splhi() is sufficient.  on a mp
system, the losing process will spin until the winning process
is finished.

ken fs does need to return to its mp roots.

- erik

Re: [9fans] kenfs question?

[Venkatesh Srinivas]

On Sat, Feb 6, 2010 at 11:16 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> ilock() (pc/lock.c) calls splhi() and then calls lock(). If that lock were contended,
>> how would the system not stop? And on a UP system, if you're inside an splhi() block,
>> why would you need to take an uncontended lock?
>
> good question.  on a up system, splhi() is sufficient.  on a mp
> system, the losing process will spin until the winning process
> is finished.
>
> ken fs does need to return to its mp roots.
>

Did kenfs ever run on MP systems and use >1 CPU?

-- vs

Re: [9fans] kenfs question?

[erik quanstrom]

> > ken fs does need to return to its mp roots.
> >
>
> Did kenfs ever run on MP systems and use >1 CPU?

yes.  on the "power" mips boxes it did:

http://www.fywss.com/plan9/plan9v2faq.html#smp

if you spend some time with the code, you'll notice that it's
designed for a fair number of processors.

- erik

Re: [9fans] kenfs question?

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

>
> ilock() (pc/lock.c) calls splhi() and then calls lock(). If that lock were
> contended, how would the system not stop? And on a UP system, if you're
> inside an splhi() block,
> why would you need to take an uncontended lock?
>

ilock is for locks that get used both in normal procs
and in interrupt handlers.  Using splhi makes sure
that the interrupt handler does not get started on the
same cpu while the proc holds the lock, which would
cause a deadlock.

If there were no interrupts involved, the lock would be
managed with lock/unlock instead of ilock/iunlock.

On a uniprocessor you could get away with splhi/splx
instead of ilock/iunlock, but it's easier and more portable
to program as if always on a multiprocessor.

Russ

[-- Attachment #2: Type: text/html, Size: 1068 bytes --]

Re: [9fans] kenfs question?

[Venkatesh Srinivas]

Hi,

I guess I wasn't clear; what I was asking was why it was safe to
attempt to take a lock when splhi() at all.

On a UP, if that lock is contended and interrupts are off, you'll
lockup, no? (The timer interrupt handler will never run, reschedule
will never happen, the lock holder will never run).

-- vs

Re: [9fans] kenfs question?

[erik quanstrom]

> I guess I wasn't clear; what I was asking was why it was safe to
> attempt to take a lock when splhi() at all.

because the rule is you can't sleep when holding a lock.

- erik

Re: [9fans] kenfs question?

[Charles Forsyth]

> I guess I wasn't clear; what I was asking was why it was safe to
> attempt to take a lock when splhi() at all.

because such a lock is always taken with splhi, using ilock.
you might find in older code the use of lock in interrupt handlers,
protected by the implicit splhi of interrupt handling, and in
a few cases explicit splhi calls before lock.

Re: [9fans] kenfs question?

[Venkatesh Srinivas]

On Sun, Feb 7, 2010 at 5:42 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>> I guess I wasn't clear; what I was asking was why it was safe to
>> attempt to take a lock when splhi() at all.
>
> because such a lock is always taken with splhi, using ilock.
> you might find in older code the use of lock in interrupt handlers,
> protected by the implicit splhi of interrupt handling, and in
> a few cases explicit splhi calls before lock.

Ah, okay. I didn't realize that.

Perhaps it'd be clearer if ilock/iunlock took a different type than lock/unlock?

Thanks!
-- vs