Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jan 2010 10:25:34 +0100
From:      Attilio Rao <attilio@freebsd.org>
To:        Neelkanth Natu <neelnatu@yahoo.com>
Cc:        freebsd-mips@freebsd.org
Subject:   Re: AR71XX RTC
Message-ID:  <3bbf2fe11001260125t43b833feha759555f3e4d0fe8@mail.gmail.com>
In-Reply-To: <3bbf2fe11001260124h423bd73ev38ba939d34155c54@mail.gmail.com>
References:  <5D3E417C-FE51-49A7-B8CC-564932BF0D3E@lakerest.net> <489828.45501.qm@web34403.mail.mud.yahoo.com> <3bbf2fe11001260124h423bd73ev38ba939d34155c54@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
2010/1/26 Attilio Rao <attilio@freebsd.org>:
> 2010/1/25 Neelkanth Natu <neelnatu@yahoo.com>:
>> Hi Randall,
>>
>> --- On Mon, 1/25/10, Randall Stewart <rrs@lakerest.net> wrote:
>>
>>> From: Randall Stewart <rrs@lakerest.net>
>>> Subject: Re: AR71XX RTC
>>> To: "Neelkanth Natu" <neelnatu@yahoo.com>
>>> Cc: "M. Warner Losh" <imp@bsdimp.com>, freebsd-mips@freebsd.org
>>> Date: Monday, January 25, 2010, 12:51 PM
>>> Neil:
>>>
>>> Thanks for the patch.. it does look good since the old
>>> code was tromping part of the old threads PCB which is
>>> definitely not right ;-0 .. I do have a question for you..
>>> forgive my ignorance..
>>>
>>> What exactly are we trying to switch here. It seems
>>> that cpu_switch(...) is now being called with
>>> oldtd, newtd and mtx...
>>>
>>> I see that the thread structure has a struct mutex *td_lock
>>> as
>>> its first member. But what is this supposed to be pointing
>>> to?
>>> And when we switch are we trying to take the
>>>
>>> oldtd->td_lock and place it into the newtd->td_lock
>>>
>>> Or?
>>>
>>> What... I guess I just don't have any context for whats
>>> going on..
>>>
>>
>> I am not very sure about this myself so take this with a grain of salt:
>>
>> When a thread is being switched out because it is on a sleep queue the
>> intent is that some other thread running on a different cpu should not b=
e
>> allowed to muck with this thread's state. To make this happen the 'td_lo=
ck'
>> of 'oldtd' is switched from what it was originally (viz. the sleep queue
>> chain lock) to 'blocked_lock'. The 'blocked_lock' is special because
>> it is always locked. This all happens in sched_switch().
>>
>> cpu_switch() is passed the original value of 'oldtd->td_lock'
>> as the third argument. When the context is switched to 'newtd' we will
>> switch back the 'oldtd->td_lock' from 'blocked_lock' to its original
>> value. And this way we don't lose any wakeups that may happen while we
>> are in sched_switch().
>>
>> At least that is my very naive understanding of it. CCing Attilio to
>> shed more light on this.
>
> Hope this little explanation may give more guidance:
> http://lists.freebsd.org/pipermail/svn-src-head/2010-January/014038.html
>
> anyways, the interesting bits in, eg. i386 are:
>
> #if defined(SMP) && defined(SCHED_ULE)
> #define SETOP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xchgl
> #define BLOCK_SPIN(reg) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0movl =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0$blocked_lock,%eax ; =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
> =C2=A0 =C2=A0 =C2=A0 =C2=A0100: ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lock ; =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cmpxchgl =C2=A0 =
=C2=A0 =C2=A0 =C2=A0%eax,TD_LOCK(reg) ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0jne =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 101f ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0\
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pause ; =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0jmp =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 100b ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0\
> =C2=A0 =C2=A0 =C2=A0 =C2=A0101:
> #else
> #define SETOP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 movl
> #define BLOCK_SPIN(reg)
> #endif
>
> The difference with SETOP is just for providing a rel memory barriers
> vs. not providing a rel memory barrier (thus be careful, if you want
> to support ULE, to follow the same logic), while BLOCK_SPIN() does:
>
> while (oldtd->td_lock =3D=3D &blocked_lock) cpu_spinwait();

s/oldtd/newtd.

Attilio


--=20
Peace can only be achieved by understanding - A. Einstein



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