> Subject: Re: jailhouse jitter? > > On 29.07.20 05:28, Peng Fan wrote: > >> Subject: Re: jailhouse jitter? > >> > >> On 27.07.20 08:56, Peng Fan wrote: > >>>> Subject: Re: jailhouse jitter? > >>>> > >>>> On 27.07.20 08:25, Peng Fan wrote: > >>>>> Hi Jan > >>>> > >>>> ... > >>>> > >>>>> > >>>>> I tested the SDEI on i.MX8MM, it shows the jitter became smaller. > >>>>> > >>>>> Without SDEI, the gic-demo jitter is 999ns+ With SDEI, the > >>>>> gic-demo jitter is 124ns~246ns. > >>>>> > >>>>> Indeed no more vmexits. > >>>>> > >>>>> But the max jitter, some times SDEI bigger only when program start > >>>>> up, > >>>> mostly because of CACHE WARM UP I think. > >>>> > >>>> That is one source. If you add a warm-up period, they can be > >>>> mitigated, though. > >>>> > >>>> The other source might be last-level cache sharing. If there are > >>>> cache-miss counters, maybe you can check if those increase along > >>>> the > >> peaks. > >>> > >>> Yes. When I add stress-ng in root cell, the jitter became larger > >>> sometimes. > >>> > >> > >> I've seen the same on the ultra96. My cache theory should be > >> validated, though, because I would have assumed that all of the gic > >> demo fits into a core-local cache. > > > > After thinking more about root cell color, when booting jailhouse before > Linux. > > > > We are not using 1:1 mapping anymore or we could use 1:1 mapping with > > many pieces of small ram area. > > I suspect Linux may not like a device tree with hundreds or thousands of > memory region entries.
True. > > > > > So I think the first 1 is better, but when use kmalloc for dma usage > > sometimes, it will bring issues, because not 1:1 mapping, unless we > > let all drivers use dedicated dma area reserved and not colored. > > We will need an SMMU for colored Linux instances. That will make things > appear 1:1 mapped again for Linux. But SMMU is really eating silicon die size, many platforms not have that. Thanks, Peng > > > > >> > >>> > >>>> > >>>>> > >>>>> Will you move SDEI support to jailhouse mainline? > >>>> > >>>> Once the to-dos are addressed. Any contributions? > >>> > >>> I'll read more into your patches and check the to-dos you listed in > >>> the jailhouse commit log to see what I could help there. > >>> > >> > >> Item one (SDEI probing) is almost resolved. > >> > >>>> > >>>> BTW, did you have to patch ATF for your experiment? Will you > >>>> upstream that patch? > >>> > >>> Yes. I'll upstream that. Quite simple, I only enabled one SDEI private > event. > >>> > >> > >> Perfect. > > > > Sent out. > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frevi > > > ew.trustedfirmware.org%2Fc%2FTF-A%2Ftrusted-firmware-a%2F%2B%2F511 > 6&am > > > p;data=02%7C01%7Cpeng.fan%40nxp.com%7C243dabd82a3449fff8b308d83 > 3a1f850 > > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6373161180330 > 65867&s > > > data=%2FNf1rQNr5fgDkE2T%2FWpWZclAom57nxCfCmtJX5nfxPs%3D&r > eserved=0 > > > > Great! Let's see how the review works out, then I could try getting my patches > ready for upstream as well. > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate > Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/DB6PR0402MB2760893A4ED60F92C6E107C088700%40DB6PR0402MB2760.eurprd04.prod.outlook.com.
