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
