Vimage next step

[Julian Elischer]

Julian Elischer wrote:
> I've been doing performance testing on the 'non-vimage' 'structified'
> case VS the original 'globals' case and have not been able to see any
> really significant differences (though I have seen very slight
> differences in the distribution of results).
> 
> SO I think we are in the position of moving forward to the next steps.
> 
> I think that just means checking in the rest of the vimage tree
> from what I have seen.
> 
> Then  we can play with it a bit and then proceed to the
> jail/vimage merge stuff that Jamie (and bz) are working on.
> 
> One thing I'd like to do is make the following changes:
> 
> 1/ evaluate the ordering of the items in the vimage structures to see if 
> there are items that should be clustered for cache reasons.
> 
> 2/ remove all sub structures from the vimage structures
> and replace them with pointers. This is because puting them in
> directly in the vimage structures will make our lives harder due to ABI 
> issues. If they are independently allocated (*) then we don't need to 
> worry about them changing in size.

for example, the ipsec struct starts with:

         int                     _ipsec_debug;
         struct  ipsecstat       _ipsec4stat;
         struct  secpolicy       _ip4_def_policy;

         int                     _ip4_esp_trans_deflev;
         int                     _ip4_esp_net_deflev;

This effectively fixes the size of the ipsecstat and secpolicy structures.
I would like instead to have:
         int                     _ipsec_debug;
         struct  ipsecstat       *_ipsec4stat;
         struct  secpolicy       *_ip4_def_policy;

         int                     _ip4_esp_trans_deflev;
         int                     _ip4_esp_net_deflev;

and have the initializer function allocate those separately.



> 
> 
> (*) actually they could still be allocated as a blob but we would access 
> them as if they are separate.
> 
> comments?
> 
> Julian
> 
> 
> 
> _______________________________________________
> freebsd-virtualization at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to 
> "freebsd-virtualization-unsubscribe at freebsd.org"