Date: Sun, 2 Oct 2011 14:03:31 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "Jayachandran C." <jchandra@freebsd.org>, Alexander Motin <mav@freebsd.org>, freebsd-mips@freebsd.org Subject: Re: svn commit: r225892 - head/sys/mips/mips Message-ID: <20111002110331.GF1511@deviant.kiev.zoral.com.ua> In-Reply-To: <CAJ-VmomLbueaG3bmnT0WfeKaMSyXSNo80BWXqEe39z6x%2Bx8QoA@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--nRb24sRrY2rSsMZw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 02, 2011 at 05:28:25PM +0800, Adrian Chadd wrote: > Hi, >=20 > It doesn't look like openbsd or netbsd have tried addressing this. >=20 > I took a shot at trying to port over the relevant bits. >=20 > 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(). >=20 > 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. >=20 > I really don't have the time or brain power at the moment to try and > port this solution over from Linux. >=20 > 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@] --nRb24sRrY2rSsMZw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6IRQMACgkQC3+MBN1Mb4imzQCgkqBbxpax7ZS0rBrGjARYiPNn X7UAn02R0lgIt0Ph2/8SllAnQbbDqfLm =FOM5 -----END PGP SIGNATURE----- --nRb24sRrY2rSsMZw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111002110331.GF1511>