On Fri, Oct 10, 2014 at 11:03:34AM +0100, James Hogan wrote: > Hi Leonid, > > On Thu, Oct 09, 2014 at 05:07:11PM -0700, Leonid Yegoshin wrote: > > On 10/09/2014 04:40 PM, James Hogan wrote: > > > You could then avoid the whole stack and per-thread thing and just have > > > a maximum of one emuframe dedicated to each thread or allocated on > > > demand, and if there genuinely is a use case for nesting later on, worry > > > about it then. > > > > As I understand, you propose to allocate some space in mmap. > > No, sorry if I wasn't very clear. I just mean that you can get away with > a single kernel managed page per mm, with an emuframe allocated > per-thread which that thread always uses, since they never nest, which I > think simplifies the whole thing significantly. > > The allocation could be smarter than that of course in case you have > thousands of threads and only a subset doing lots of FP branches, but a > single thread should never need more than one at a time since the new > signal behaviour effectively makes the delay slot emulation sort of > atomic from the point of view of usermode, and the kernel knows for sure > whether BD emulation is in progress from the PC. > > (If there is some other way than signals that I haven't taken into > account that the emulation could be pre-empted then please let me know!) Right, look at uprobes, it does exactly all this with a single page. Slot allocation will block waiting for a free slot when all are in use. If you need to support nesting, you need to do greedy slot allocation, which is possible with limited nesting.
