On Tue, Jul 28, 2020 at 11:26:45AM +0200, Jan Kiszka wrote: > On 28.07.20 11:15, Marco Solieri wrote: > > On Mon, Jul 27, 2020 at 11:39:48PM +0200, Jan Kiszka wrote: > > > On 27.07.20 23:13, Marco Solieri wrote: > > > > If we understand correctly your > > > > implementation, you are mapping the entire memory region and then > > > > copying blocks of the binary image using what you called "colored > > > > offset" function. That was very similar to our first (unpublished) > > > > attempt to implement "colored loading", and we soon discovered it is not > > > > very efficient. Loading time grows considerably and could impede > > > > scaling up to larger images (e.g. an Ubuntu-like rootfs). We think that > > > > a better alternative is closer to what we proposed in the last patchset, > > > > that is: > > > > - create a colored mapping, > > > > - perform a "virtually" contiguous copy of the image. > > > > > > > > We understand that this logic has to be moved outside the hypervisor, so > > > > we would like to move it to the driver, exploiting Linux virtual addres > > > > space to create the colored mapping. What do you think about it? > > > > > > Did you examine what was causing this slowdown? It seems highly > > > counter-intuitive to me, given that we are only copying from memory to > > > memory in 4K chunks, just using different virtual addresses - that' all. > > > > I think you are right, indeed. Doublechecking our old (and slow) > > prototype, we discovered we were actually not just copying at each > > iteration step, but we were also been ioremapping. That was most > > probably the cause of the slowdown. > > > > That leaves only a design point in favour of the contiguous virtual > > mapping. It makes the implementation more robust and elegant, since it > > enables the copy operation to be independent from coloring and thus > > reusable. This is enough for us to favour this approach. > > > > To my understanding, the choice is between: > > for_each_colored_chunk > copy_chunk > > and > > for_each_colored_chunk > remap_chunk > copy_whole image > drop_mapping > > As the first option can be reused for uncolored images as well, I do not > really see the value of option 2. Prove me wrong by code ;).
I see. I would easily agree with you if we assume to use the `jailhouse_get_colored_offs` (or something similar), but we rather not do so. Instead, the `next_colored` function should be favored as the fundamental coloring algorithm implementation, because it is closer to the hardware meaning of coloring, in the sense that it preserves the notion of bits in the address, instead of abstracting it away behind the notion of offsets in the memory space. As a by-product, the implementation is also more flexible and generic, since it could be applied also to different kind of coloring, e.g. to bank coloring. In these cases, nasty placement of useful bits could make an "offset-oriented" implementation hard to read (and also very difficult to write :-P). E.g., consider a case where only 12 and 14 need to be used for a 4-colors platform configuration. Beside the "offset vs next_col" choice. We would like to stress that we need it to be aligned with the concept of colored memory that we are proposing in v2. This notion is present: in the user configuration and documentation, and also in the hypervisor code. Namely, given a color assignment, a memory region, and a size, we want to map *only* the needed pages that satisfy the size request. I.e., not to assign *all* the pages of the given colors within the given region, possibly exceeding the size request. In other words, the size parameter is meant as the real size to be mapped, not the place where the find it. -- Marco Solieri, Ph.D. Research Fellow High-Performance Real-Time Lab Università degli Studi di Modena e Reggio Emilia Ufficio 1.35 - Edificio Matematica - 213/b, via Campi - 41125 Modena Tel: +39-059-205-55-10 -- OpenPGP: 0x75822E7E -- 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 jailhouse-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/20200728110945.w4o52pgtq33ic2pv%40carbon.xt3.it.
signature.asc
Description: PGP signature
