Date: Mon, 3 Oct 2011 22:19:24 +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%2B7sy7A%2Bq_N6Hr%2B3-tD=BJxmqtDgBeWF9HJCtopLF0RUz6hVyw@mail.gmail.com> In-Reply-To: <20111002110331.GF1511@deviant.kiev.zoral.com.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--0016e65a076edd4d3304ae67c16c Content-Type: text/plain; charset=ISO-8859-1 Hi Adrain, On Sun, Oct 2, 2011 at 4:33 PM, Kostik Belousov <kostikbel@gmail.com> wrote: > 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 potentially > we have a runnable thread. > > Briefly looking over the MIPS64 specifications, I do not see why we cannot > 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... JC. --0016e65a076edd4d3304ae67c16c Content-Type: text/x-patch; charset=US-ASCII; name="mips_wait.patch" Content-Disposition: attachment; filename="mips_wait.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gtbp1rwu1 ZGlmZiAtLWdpdCBhL3N5cy9taXBzL2luY2x1ZGUvbWRfdmFyLmggYi9zeXMvbWlwcy9pbmNsdWRl L21kX3Zhci5oCmluZGV4IGMyYTYxNTUuLjZmNjVhMGYgMTAwNjQ0Ci0tLSBhL3N5cy9taXBzL2lu Y2x1ZGUvbWRfdmFyLmgKKysrIGIvc3lzL21pcHMvaW5jbHVkZS9tZF92YXIuaApAQCAtNTYsNiAr NTYsNyBAQCB2b2lkIE1pcHNTd2l0Y2hGUFN0YXRlKHN0cnVjdCB0aHJlYWQgKiwgc3RydWN0IHRy YXBmcmFtZSAqKTsKIHVfbG9uZwlrdnRvcCh2b2lkICphZGRyKTsKIGludAlpc19jYWNoZWFibGVf bWVtKHZtX3BhZGRyX3QgYWRkcik7CiB2b2lkCW1pcHNfZ2VuZXJpY19yZXNldCh2b2lkKTsKK3Zv aWQJbWlwc193YWl0KHZvaWQpOwogCiAjZGVmaW5lCU1JUFNfREVCVUcgICAwCiAKZGlmZiAtLWdp dCBhL3N5cy9taXBzL21pcHMvZXhjZXB0aW9uLlMgYi9zeXMvbWlwcy9taXBzL2V4Y2VwdGlvbi5T CmluZGV4IDcyOTM5MWUuLjRkMTM0NmQgMTAwNjQ0Ci0tLSBhL3N5cy9taXBzL21pcHMvZXhjZXB0 aW9uLlMKKysrIGIvc3lzL21pcHMvbWlwcy9leGNlcHRpb24uUwpAQCAtNTU3LDYgKzU1NywzNCBA QCBOTk9OX0xFQUYoTWlwc1VzZXJHZW5FeGNlcHRpb24sIENBTExGUkFNRV9TSVosIHJhKQogCS5z ZXQJYXQKIEVORChNaXBzVXNlckdlbkV4Y2VwdGlvbikKIAorCS5hbGlnbiA0CisJLnNldAlwdXNo CisJLnNldAlub2F0CitOT05fTEVBRihtaXBzX3dhaXQsIENBTExGUkFNRV9TSVosIHJhKQorCVBU Ul9TVUJVICAgICAgICBzcCwgc3AsIENBTExGUkFNRV9TSVoKKwkubWFzayAgIDB4ODAwMDAwMDAs IChDQUxMRlJBTUVfUkEgLSBDQUxMRlJBTUVfU0laKQorCVJFR19TICAgcmEsIENBTExGUkFNRV9S QShzcCkJCSMgc2F2ZSBSQQorCW1mYzAJdDAsIE1JUFNfQ09QXzBfU1RBVFVTCisJeG9yaQl0MSwg dDAsIE1JUFNfU1JfSU5UX0lFCisJbXRjMAl0MCwgTUlQU19DT1BfMF9TVEFUVVMKKwlqYWwJc2No ZWRfcnVubmFibGUKKwlub3AKKwlSRUdfTCAgIHJhLCBDQUxMRlJBTUVfUkEoc3ApCisJbWZjMAl0 MCwgTUlQU19DT1BfMF9TVEFUVVMKKwlvcmkJdDEsIHQwLCBNSVBTX1NSX0lOVF9JRQorCW5vcAor CW5vcAorU3RhcnRXYWl0U2tpcDoJCQkJIyB0aGlzIGlzIDE2IGJ5dGUgYWxpZ25lZAorCW10YzAJ dDAsIE1JUFNfQ09QXzBfU1RBVFVTCisJYm5legl2MCwgRW5kV2FpdFNraXAKKwlub3AKKwl3YWl0 CitFbmRXYWl0U2tpcDoJCQkJIyBTdGFydFdhaXRTa2lwICsgMTYKKwlqcglyYQorCVBUUl9BRERV ICAgICAgICBzcCwgc3AsIENBTExGUkFNRV9TSVoKK0VORChtaXBzX3dhaXQpCisJLnNldAlwb3AK KwogLyotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgKgogICogTWlwc0tlcm5JbnRyIC0tCkBAIC01Nzgs NiArNjA2LDE5IEBAIE5OT05fTEVBRihNaXBzS2VybkludHIsIEtFUk5fRVhDX0ZSQU1FX1NJWkUs IHJhKQogCS5zZXQJbm9hdAogCVBUUl9TVUJVCXNwLCBzcCwgS0VSTl9FWENfRlJBTUVfU0laRQog CS5tYXNrCTB4ODAwMDAwMDAsIChDQUxMRlJBTUVfUkEgLSBLRVJOX0VYQ19GUkFNRV9TSVpFKQor CisvKgorICogQ2hlY2sgZm9yIGdldHRpbmcgaW50ZXJydXB0cyBqdXN0IGJlZm9yZSB3YWl0Cisg Ki8KKwlNRkMwCWswLCBNSVBTX0NPUF8wX0VYQ19QQworCW9yaQlrMCwgMHhmCisJeG9yaQlrMCwg MHhmCQkJIyAxNiBieXRlIGFsaWduCisJUFRSX0xBCWsxLCBTdGFydFdhaXRTa2lwCisJYm5lCWsw LCBrMSwgMWYKKwlub3AKKwlQVFJfQUREVSBrMSwgMTYJCQkjIHNraXAgb3ZlciB3YWl0CisJTVRD MAlrMSwgTUlQU19DT1BfMF9FWENfUEMKKzE6CiAvKgogICogIFNhdmUgQ1BVIHN0YXRlLCBidWls ZGluZyAnZnJhbWUnLgogICovCmRpZmYgLS1naXQgYS9zeXMvbWlwcy9taXBzL21hY2hkZXAuYyBi L3N5cy9taXBzL21pcHMvbWFjaGRlcC5jCmluZGV4IGY3ZTUyNDguLmEwNzI1YTkgMTAwNjQ0Ci0t LSBhL3N5cy9taXBzL21pcHMvbWFjaGRlcC5jCisrKyBiL3N5cy9taXBzL21pcHMvbWFjaGRlcC5j CkBAIC00OTcsNyArNDk3LDcgQEAgY3B1X2lkbGUoaW50IGJ1c3kpCiAJCWNyaXRpY2FsX2VudGVy KCk7CiAJCWNwdV9pZGxlY2xvY2soKTsKIAl9Ci0JX19hc20gX192b2xhdGlsZSAoIndhaXQiKTsK KwltaXBzX3dhaXQoKTsKIAlpZiAoIWJ1c3kpIHsKIAkJY3B1X2FjdGl2ZWNsb2NrKCk7CiAJCWNy aXRpY2FsX2V4aXQoKTsK --0016e65a076edd4d3304ae67c16c--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B7sy7A%2Bq_N6Hr%2B3-tD=BJxmqtDgBeWF9HJCtopLF0RUz6hVyw>