Re: [PATCH v2 5/6] mips: use per-mm page to execute FP branch delay slots

[Ralf Baechle <ralf@linux-mips.org>]

On Fri, Jul 04, 2014 at 10:06:01AM +0100, Paul Burton wrote:

> > The actual piece of code that needs to be installed is tiny.  So the page
> > could be shared between many threads.  In fact a single page would
> > suffice for most processes and only threads would require more slots
> > than provided by a single page so more pags could be allocated or the
> > process could sleep until a slot becomes available.
> 
> You just roughly described the v2 patch that we're replying to :)

Can't be that wrong then :-)

I seem to only have replies to that patch in my mail folder not the
patch itself.

> The problem is how to reliably free the frame after it has been used.
> I can see ways to do it, but none that are particularly "nice".
> 
> > Assuming the smallest supported page size of 4k and slots of 128 bytes
> > (that is the largest S-cache line size in common use) that's 32 slots.
> 
> Why S-cache line sized slots? I suppose it could simplify updating the
> page slightly at the cost of space.

That's to handle the worst case - R4000/R4400 SC and MC variants it is
possible to split the S-cache as SI-cache and SD-cache.  That means
modified instructions need to be written back all the way to memory
otherwise potencially stale instructions might be fetched from the
SI-cache.

That's more theoretical - I'm not aware of any system that's using split
S-caches.  Still using S-cache line sized slots might reduce the cache
line ping pong on multi-core systems a bit.

> > I'm also wondering how insane emulation would be.  We already have the
> > capability to emulate a fair fraction of the instruction set.
> 
> Yeah, and I'm reasonably sure we're going to need some more once MIPSr6
> is supported. I guess (perhaps only for the short term?) it could be
> done in stages - if systems include ASEs or cop2 that the emulation
> didn't implement then it could fall back to the current emuframe code.

And it's dependence on executable stackframe ...

> I'm in 2 minds about this - it sounds crazy but perhaps it's the most
> sane option available :)

Sanity is overrated anyway ;-)

  Ralf