The kernel summit dedicated a slot on its second-day agenda to the
presentation of more minisummit reports and lightning talks. First up was
Chris Wright, who reported from the virtualization minisummit held last
April in Austin. The developers at the minisummit learned a lot about the
hardware roadmaps maintained by various vendors. There was talk of
improving cooperation with Qemu. The possibility of VMWare open-sourcing
its user-space tools was raised, though, it seems, there is no prospect of
getting that company's drivers released. The problem with the drivers is
not legal; it's just that they are so tightly integrated with the VMWare
hypervisor that there is little point in putting them out there.
Beyond that, there were a number of discussions on topics (like
checkpoint/resume) which have since turned into code. And it was noted
that the virtualization developers would like improved hugetlb support.
In particular, they like the active defragmentation patches which make it
more likely that huge page allocations will succeed.
David Miller discussed the 2008 networking minisummit, otherwise known as a
couple of developers wandering by his house to discuss ideas. He mainly
talked about the multi-queue
work, which has been covered on LWN separately. One interesting point
to note is that, while multi-queue is useful for wireless networking, it is
also an important high-end scalability improvement. When the system tries
to drive a 10GB network card at full speed, the locking contention on a
single queue gets to be a significant performance problem.
Matt Mackall presented his bloatwatch work, which monitors
the text and data sizes of kernel releases. Unsurprisingly, the kernel is
getting larger over time - a development which does not please embedded
systems vendors. Bloatwatch allows interested people to see which code
changes caused a given kernel release to grow. Matt would like to have
more people using this tool and trying to keep a lid on kernel growth.
It was suggested that bloatwatch could be run against linux-next and used
to catch bloat before it gets into the mainline. Linus asked if growth
could be correlated with the information in the git repository, making it
possible to shame individual developers.
Overall, it was noted that kernel growth is lagging far behind Moore's law,
suggesting that the kernel is requiring a smaller portion of system memory
over time. Still, it would be good to use even less; Matt figures that
about half the growth in the kernel is something which can be avoided with
to post comments)