| |||||||||||||
KS2008: more minisummit reports
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 some thought. (Log in to post comments)
|
|||||||||||||