|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
xen-devel
[Xen-devel] credit2 data structures
 
George,
while hunting down direct assignments of cpumask_t variables (which I'm
trying to eliminate so that hypervisor binaries built for many CPUs won't
have undue memory overhead on "normal" [smaller] systems), I stumbled
across memory references that at the first glance looked buggy to me
due to their huge immediates. As it turns out, they're not buggy but a
result of credit2's struct csched_private - particularly having a NR_CPUS
sized array of struct csched_runqueue_data, which in turn has three
cpumask_t-s, totaling to a structure size of about 6.5Mb when building
for 4095 CPUs (the current upper limit in Xen).
Apart from the possibility of allocating the arrays (and maybe also the
cpumask_t-s) separately (for which I can come up with a patch on top
of what I' currently putting together) - is it really necessary to have
all these, the more that there can be multiple instances of the structure
with CPU pools?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 
 |   
 
| <Prev in Thread] | 
Current Thread | 
[Next in Thread>
 |  
- [Xen-devel] credit2 data structures,
Jan Beulich <=
 
 
 |  
  
 | 
    | 
  
  
    |   | 
    |