You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've plottet a histogram of IPC payload size for cycleburner boot and running cycleburner for a couple of seconds. Sitting behind a UMTS connection prevents me from downloading meaningful vancouver setup. Still I think even in a vancouver setup IPC characteristics should not be completely different.
In most cases there are only a few items, that's true. But there are also cases, like storage where DMA descriptors are put into the UTCB, where it might be something like 1KB. Although we don't need another layer on top of that in this case. I think we should at least run a serious test like linux kernel compile or disk benchmark or something and see how often stacking is needed, how much items are in there and whether it makes a performance difference.
But yeah, I'm also a bit skeptical whether it makes a measurable difference in some usecase. I only would like to test it until we throw away the solution :)
Btw, if somebody is wondering: actually we are not talking about removing stackable UTCBs, but only whether there should be kernel support for it that allows us to stack UTCBs without copying anything :)
I've plottet a histogram of IPC payload size for cycleburner boot and running cycleburner for a couple of seconds. Sitting behind a UMTS connection prevents me from downloading meaningful vancouver setup. Still I think even in a vancouver setup IPC characteristics should not be completely different.
http://i45.tinypic.com/2jb5fl4.png
As you can see, the largest observed IPC has 9 untyped items. I am not convinced that stacking UTCBs makes any meaningful performance difference. :)
The text was updated successfully, but these errors were encountered: