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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"[email protected]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"[email protected]"
