Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Oct 2011 03:23:11 +0530
From:      "Jayachandran C." <jchandra@freebsd.org>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        Kostik Belousov <kostikbel@gmail.com>, Alexander Motin <mav@freebsd.org>, freebsd-mips@freebsd.org
Subject:   Re: svn commit: r225892 - head/sys/mips/mips
Message-ID:  <CA%2B7sy7Cin5-cHcP-8_qYGhpEnAN9gw6S5ekXYK6Q3X9FREQggA@mail.gmail.com>
In-Reply-To: <CA%2B7sy7Ax9SXSK1CyxuBNboktJxuQTMiu3D4NFmZSoq7-ipoQgA@mail.gmail.com>
References:  <CA%2B7sy7BiRvTB79H9=y%2BS4jQ=%2BboW1bcDJn%2BBULMmJU9KLLVJ5A@mail.gmail.com> <CAJ-VmokAsDpjJLt%2BVJ2gDGX%2BiMAwZvL2TPaaAD_LRm-Yyquxig@mail.gmail.com> <CA%2B7sy7D6h5a08Q6yNfX6xSqwabDLzE5GLu5aV3fCMYQKn_4AoQ@mail.gmail.com> <CAJ-Vmon32cVEVvC=3WJVmDkCUdyLWyec3sqU-ifzspVSPxedfg@mail.gmail.com> <CAJ-Vmomsq5PQzbCBmWob5juB9EqdcEoYV%2B9vwYjnJQYTo_%2B4kw@mail.gmail.com> <CAJ-Vmon_a_zLZmEGqwFaYaobjYFE2i1u2Viq3QD5dw4wpNNURA@mail.gmail.com> <CA%2B7sy7DFCMxo-2bJwBJcSEJf7ewG7Y=XwdgKXkhpRyDXQpvsYA@mail.gmail.com> <CAJ-VmokPFqS2oNWZ_mFSxy=0MXfgqtOcBHSQe%2BdYXvsLHAyGjQ@mail.gmail.com> <CAJ-VmomqmKPRHBCbt46_xXD0VoU47Q-vYWbAqCFaM635ZnOHWA@mail.gmail.com> <CAJ-VmomLbueaG3bmnT0WfeKaMSyXSNo80BWXqEe39z6x%2Bx8QoA@mail.gmail.com> <20111002110331.GF1511@deviant.kiev.zoral.com.ua> <CA%2B7sy7A%2Bq_N6Hr%2B3-tD=BJxmqtDgBeWF9HJCtopLF0RUz6hVyw@mail.gmail.com> <CA%2B7sy7Ax9SXSK1CyxuBNboktJxuQTMiu3D4NFmZSoq7-ipoQgA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--0016e6d5895955a1c904ae6c0098
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 4, 2011 at 12:34 AM, Jayachandran C. <jchandra@freebsd.org> wro=
te:
> On Mon, Oct 3, 2011 at 10:19 PM, Jayachandran C. <jchandra@freebsd.org> w=
rote:
>> Hi Adrain,
>>
>> On Sun, Oct 2, 2011 at 4:33 PM, Kostik Belousov <kostikbel@gmail.com> wr=
ote:
>>> On Sun, Oct 02, 2011 at 05:28:25PM +0800, Adrian Chadd wrote:
>>>> Hi,
>>>>
>>>> It doesn't look like openbsd or netbsd have tried addressing this.
>>>>
>>>> I took a shot at trying to port over the relevant bits.
>>>>
>>>> Linux seems to store the "can reschedule" flag in a bit of memory,
>>>> rather than calling a function to check each time.
>>>> This means that I can't simply port r4k_wait() verbose; there's no
>>>> guarantee EPC would be pointing to inside r4k_wait if it had to call
>>>> sched_runnable().
>>>>
>>>> Also, since we are calling 'wait' inside a critical section, any EPC
>>>> unwinding would have to also unwind the critical section (and maybe
>>>> reprogram the timer) before restarting things. But since that now
>>>> makes the "rollback" section even larger and unwieldy.
>>>>
>>>> I really don't have the time or brain power at the moment to try and
>>>> port this solution over from Linux.
>>>>
>>>> I would really appreciate it if someone would help out here.
>>>
>>> I probably need to describe some details of the mentioned "kib' idea".
>>>
>>> Looking at the x86 sti; hlt sequence, I noted that, in fact, we do
>>> not strictly need the special CPU behaviour of delaying enabling the
>>> interrupts till next instruction after sti is executed. The race there
>>> is the interrupt happen right after sti but before hlt, causing CPU
>>> to enter halted state while potentially having runnable thread. On x86
>>> it is closed by sti not enabling interrupts till hlt started execution
>>> (it is more subtle, but let ignore the detail for the discussion).
>>>
>>> Now, if sti would not offer the useful postponing behaviour, we can
>>> easily emulate it. In the hardware interrupt handlers return path, we
>>> can check for $pc being equal to the address of the hlt instruction. If
>>> it is, we can advance $pc over the hlt, avoiding the halt if potentiall=
y
>>> we have a runnable thread.
>>>
>>> Briefly looking over the MIPS64 specifications, I do not see why we can=
not
>>> implement the spirit of the trick for the ei; wait instruction sequence=
.
>>> ray talked about possibility of $pc living in the shadow register bank,
>>> which I think is not important. Another (minor) issue seems to be
>>> that our code does not use ei, directly manipulating the bit.
>>>
>>> My belief is that the trick can be done if only we have exact
>>> interrupts. It seems, from "run mips run" text, that possible inexact
>>> interrupts are either for much older platforms then modern MIPS SoC, or
>>> are irrelant there, because inexactness is only related to mul/div unit=
.
>>>
>>> [I am not on mips@]
>>
>> I have implemented a variant of this, can you try out the attached
>> patch and see how it goes? It should apply on the version before your
>> changes to machdep.c
>>
>> Also, if anybody on mips@ can review the code, it would be helpful...
>
> Actually there are two issues with this, the first is a simple bug, it
> should be :
> mtc0 =A0 =A0t1, MIPS_COP_0_STATUS
>
> The second one is that a move to the status register should followed
> by a COP0 write hazard on some mips platforms (although not on
> XLR/XLP). Adding this hazard would make the calculations more
> complex....

This version should be better(thanks to Juli for suggestions).  Can
you see if this helps?

Thanks,
JC

--0016e6d5895955a1c904ae6c0098
Content-Type: application/octet-stream; name="mips_wait2.patch"
Content-Disposition: attachment; filename="mips_wait2.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gtbzwzny0

ZGlmZiAtLWdpdCBhL3N5cy9taXBzL2luY2x1ZGUvbWRfdmFyLmggYi9zeXMvbWlwcy9pbmNsdWRl
L21kX3Zhci5oCmluZGV4IGMyYTYxNTUuLjZmNjVhMGYgMTAwNjQ0Ci0tLSBhL3N5cy9taXBzL2lu
Y2x1ZGUvbWRfdmFyLmgKKysrIGIvc3lzL21pcHMvaW5jbHVkZS9tZF92YXIuaApAQCAtNTYsNiAr
NTYsNyBAQCB2b2lkIE1pcHNTd2l0Y2hGUFN0YXRlKHN0cnVjdCB0aHJlYWQgKiwgc3RydWN0IHRy
YXBmcmFtZSAqKTsKIHVfbG9uZwlrdnRvcCh2b2lkICphZGRyKTsKIGludAlpc19jYWNoZWFibGVf
bWVtKHZtX3BhZGRyX3QgYWRkcik7CiB2b2lkCW1pcHNfZ2VuZXJpY19yZXNldCh2b2lkKTsKK3Zv
aWQJbWlwc193YWl0KHZvaWQpOwogCiAjZGVmaW5lCU1JUFNfREVCVUcgICAwCiAKZGlmZiAtLWdp
dCBhL3N5cy9taXBzL21pcHMvZXhjZXB0aW9uLlMgYi9zeXMvbWlwcy9taXBzL2V4Y2VwdGlvbi5T
CmluZGV4IDcyOTM5MWUuLmFhZDBjN2EgMTAwNjQ0Ci0tLSBhL3N5cy9taXBzL21pcHMvZXhjZXB0
aW9uLlMKKysrIGIvc3lzL21pcHMvbWlwcy9leGNlcHRpb24uUwpAQCAtNTU3LDYgKzU1NywzMyBA
QCBOTk9OX0xFQUYoTWlwc1VzZXJHZW5FeGNlcHRpb24sIENBTExGUkFNRV9TSVosIHJhKQogCS5z
ZXQJYXQKIEVORChNaXBzVXNlckdlbkV4Y2VwdGlvbikKIAorCS5zZXQJcHVzaAorCS5zZXQJbm9h
dAorTk9OX0xFQUYobWlwc193YWl0LCBDQUxMRlJBTUVfU0laLCByYSkKKwlQVFJfU1VCVSAgICAg
ICAgc3AsIHNwLCBDQUxMRlJBTUVfU0laCisJLm1hc2sgICAweDgwMDAwMDAwLCAoQ0FMTEZSQU1F
X1JBIC0gQ0FMTEZSQU1FX1NJWikKKwlSRUdfUyAgIHJhLCBDQUxMRlJBTUVfUkEoc3ApCQkjIHNh
dmUgUkEKKwltZmMwCXQwLCBNSVBTX0NPUF8wX1NUQVRVUworCXhvcmkJdDEsIHQwLCBNSVBTX1NS
X0lOVF9JRQorCW10YzAJdDEsIE1JUFNfQ09QXzBfU1RBVFVTCisJQ09QMF9TWU5DCisJamFsCXNj
aGVkX3J1bm5hYmxlCisJbm9wCisJUkVHX0wgICByYSwgQ0FMTEZSQU1FX1JBKHNwKQorCW1mYzAJ
dDAsIE1JUFNfQ09QXzBfU1RBVFVTCisJb3JpCXQxLCB0MCwgTUlQU19TUl9JTlRfSUUKKwkuYWxp
Z24gNAorU3RhcnRXYWl0U2tpcDoJCQkJIyB0aGlzIGlzIDE2IGJ5dGUgYWxpZ25lZAorCW10YzAJ
dDEsIE1JUFNfQ09QXzBfU1RBVFVTCisJYm5legl2MCwgRW5kV2FpdFNraXAKKwlub3AKKwl3YWl0
CitFbmRXYWl0U2tpcDoJCQkJIyBTdGFydFdhaXRTa2lwICsgMTYKKwlqcglyYQorCVBUUl9BRERV
ICAgICAgICBzcCwgc3AsIENBTExGUkFNRV9TSVoKK0VORChtaXBzX3dhaXQpCisJLnNldAlwb3AK
KwogLyotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgKgogICogTWlwc0tlcm5JbnRyIC0tCkBAIC01Nzgs
NiArNjA1LDE5IEBAIE5OT05fTEVBRihNaXBzS2VybkludHIsIEtFUk5fRVhDX0ZSQU1FX1NJWkUs
IHJhKQogCS5zZXQJbm9hdAogCVBUUl9TVUJVCXNwLCBzcCwgS0VSTl9FWENfRlJBTUVfU0laRQog
CS5tYXNrCTB4ODAwMDAwMDAsIChDQUxMRlJBTUVfUkEgLSBLRVJOX0VYQ19GUkFNRV9TSVpFKQor
CisvKgorICogQ2hlY2sgZm9yIGdldHRpbmcgaW50ZXJydXB0cyBqdXN0IGJlZm9yZSB3YWl0Cisg
Ki8KKwlNRkMwCWswLCBNSVBTX0NPUF8wX0VYQ19QQworCW9yaQlrMCwgMHhmCisJeG9yaQlrMCwg
MHhmCQkJIyAxNiBieXRlIGFsaWduCisJUFRSX0xBCWsxLCBTdGFydFdhaXRTa2lwCisJYm5lCWsw
LCBrMSwgMWYKKwlub3AKKwlQVFJfQUREVSBrMSwgMTYJCQkjIHNraXAgb3ZlciB3YWl0CisJTVRD
MAlrMSwgTUlQU19DT1BfMF9FWENfUEMKKzE6CiAvKgogICogIFNhdmUgQ1BVIHN0YXRlLCBidWls
ZGluZyAnZnJhbWUnLgogICovCmRpZmYgLS1naXQgYS9zeXMvbWlwcy9taXBzL21hY2hkZXAuYyBi
L3N5cy9taXBzL21pcHMvbWFjaGRlcC5jCmluZGV4IGY3ZTUyNDguLmEwNzI1YTkgMTAwNjQ0Ci0t
LSBhL3N5cy9taXBzL21pcHMvbWFjaGRlcC5jCisrKyBiL3N5cy9taXBzL21pcHMvbWFjaGRlcC5j
CkBAIC00OTcsNyArNDk3LDcgQEAgY3B1X2lkbGUoaW50IGJ1c3kpCiAJCWNyaXRpY2FsX2VudGVy
KCk7CiAJCWNwdV9pZGxlY2xvY2soKTsKIAl9Ci0JX19hc20gX192b2xhdGlsZSAoIndhaXQiKTsK
KwltaXBzX3dhaXQoKTsKIAlpZiAoIWJ1c3kpIHsKIAkJY3B1X2FjdGl2ZWNsb2NrKCk7CiAJCWNy
aXRpY2FsX2V4aXQoKTsK
--0016e6d5895955a1c904ae6c0098--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B7sy7Cin5-cHcP-8_qYGhpEnAN9gw6S5ekXYK6Q3X9FREQggA>