vimage and curvnet.

Julian Elischer julian at elischer.org
Fri Sep 19 19:36:54 UTC 2008


Marko Zec wrote:
> On Friday 19 September 2008 19:55:04 Julian Elischer wrote:
>> Marko Zec wrote:
>>> http://perforce.freebsd.org/chv.cgi?CH=150125
>>>
>>> Change 150125 by zec at zec_tpx32 on 2008/09/19 17:43:14
>>>
>>> 	curvnet is never set on entry to sysctl handlers, thus
>>> 	set the vnet context via TD_TO_VNET(curthread), because
>>> 	all threads must have a cred->vimage->vnet context set.
>> it seems to me that vnet is an important enough variable that we
>                       ^^^^
> I guess you meant curvnet?
> 
>> could put it in the pcpu structure and have the scheduler set it up
>> on context switches when vimage is compiled in.
> 
> Right now curvnet is defined in vimage.h as
> 
> #define curvnet curthread->td_vnet
> 
> Note that there's also a helper field in struct thread called 
> td_vnet_lpush aimed at tracing CURVNET_SET() stacking as well as 
> finding places when CURVNET_RESTORE() is not called after 
> CURVNET_SET().  Both td_vnet and td_vnet_lpush _must_ be stored with 
> each thread anyhow, given that threads can migrate practically at any 
> time.

not without the scheduler knowing about it they can't.

i.e. if the scheduler changes curvnet when it changes curthread
then it will always be correct.


> 
> So, if pcpu shadowing of curthread->td_vnet could yield performace 
> improvements than this would make sense,

It might, and it may remove some requirements for files to include proc.h

  but we would still need to
> keep td_vnet as a field in struct thread, and have CURVNET_SET() and 
> CURVNET_RESTORE() macros atomically update both the td_ field and its 
> pcpu shadow, which would require each CURVNET_XXX() macro to include 
> critical_enter() / _exit() invocations...

sure, well, if a running thread has curvnet in the pcpu field
and it is put back in the the thread struct on deschedule.
then what in td_vnet while the thread is running is not really important.

anyhow, it's just an idea.


> 
> 
>> thus it would always be directly available.
>> i.e. %gs:CURVNET_OFFSET  or whatever the syntax is on x86
>> and the equivalent on other architectures.
>>
>>> Affected files ...
>>>
>>> .. //depot/projects/vimage-commit2/src/sys/netinet/tcp_subr.c#14
>>> edit
>>>
>>> Differences ...
>>>
>>> ==== //depot/projects/vimage-commit2/src/sys/netinet/tcp_subr.c#14
>>> (text+ko) ====
>>>
>>> @@ -119,7 +119,7 @@
>>>  static int
>>>  sysctl_net_inet_tcp_mss_check(SYSCTL_HANDLER_ARGS)
>>>  {
>>> -	INIT_VNET_INET(curvnet);
>>> +	INIT_VNET_INET(TD_TO_VNET(curthread));
>>>  	int error, new;
>>>
>>>  	new = V_tcp_mssdflt;
>>> @@ -141,7 +141,7 @@
>>>  static int
>>>  sysctl_net_inet_tcp_mss_v6_check(SYSCTL_HANDLER_ARGS)
>>>  {
>>> -	INIT_VNET_INET6(curvnet);
>>> +	INIT_VNET_INET6(TD_TO_VNET(curthread));
>>>  	int error, new;
>>>
>>>  	new = V_tcp_v6mssdflt;
> 



More information about the freebsd-virtualization mailing list