Re: [PATCH v2 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack
From: Peter Zijlstra
Date: Fri Oct 10 2014 - 06:24:43 EST
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/