Date: Thu, 19 Feb 2009 15:26:21 -0800 From: Julian Elischer <julian@elischer.org> To: FreeBSD virtualization mailing list <freebsd-virtualization@freebsd.org>, Marko Zec <zec@FreeBSD.org>, "Bjoern A. Zeeb" <bz@FreeBSD.org> Subject: Re: Vimage next step Message-ID: <499DEA9D.70105@elischer.org> In-Reply-To: <499DC0F7.10709@elischer.org> References: <499DC0F7.10709@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to
> "freebsd-virtualization-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?499DEA9D.70105>