|
|
|
|
|
|
|
|
|
|
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 <=
|
|
|
|
|