LWN.net Logo

Kernel Summit: Short topics

The last topic on Monday was the "five-minute speed talks," where developers could briefly raise an issue of interest to them.

Linus started things off by talking about 2.7. It seems that he is getting very few complaints about the 2.6 kernel; just about everybody, it seems, is quite happy with it. Says Linus: "that's not good." Without a list of outstanding issues, there is little pressure to start the 2.7 development series; why bother, if there's nothing to do?

He has another concern as well. Linus believes that working as a two-person team with Andrew Morton has been highly effective. Nobody was prepared to disagree with him on that point. When 2.7 starts, Andrew will stay with 2.6 and that partnership will end - or, at least, change significantly. Finding somebody to take Andrew's place will be a tall order, to say the least.

2.7 is a topic which is to be revisited at the end of the Tuesday session.

Matthew Wilcox noted that PCI Express is taking off more quickly than had been anticipated, and that PCI Express video cards will likely displace AGP cards in the near future. Linux, thus, needs to get proper PCI Express support in place quickly. For various reasons, getting this support in place will require some memory management changes: PCI Express memory windows require new attributes which can only be set up using the newish "physical attribute table" (PAT) mechanism.

Paul McKenney claimed that some scalability issues remain in the kernel; he talked specifically about the dentry cache. Dentry aging is still done globally, and the relevant locking slows things down. Fixing this issue will require some significant rewrites, and is thus a 2.7 issue.

Andrew Morton was a bit annoyed, wondering why he had not heard about this issue until now. It seems that, since nobody expects the problem to be fixed in 2.6, it hasn't seen much public discussion so far.

Linus discussed the need for a cache for the readdir() VFS operation. Of all the filesystem operations, only readdir() remains uncached, and it is a performance problem in some situations - it hits Samba servers in particular. Part of that problem is the result of Samba's implementation of case-insensitive lookups, a feature which is unlikely to ever find its way into the mainline kernel. Some sort of readdir() caching may be added, instead, but it will not be trivial; among other things, some directories can be quite large and thus hard to cache.

Other topics which came up included the early user space/initramfs work (which, says Linus, "will never happen," but which is apparently being shipped now by SUSE); the creation of a set of ABI header files for the kernel (which looks like a high priority for 2.7); whether OSDL should be doing more testing for the community (the real need, instead, is more people looking at the tests being done now); and the eternal goal of rewriting the TTY layer (which works "just well enough" that nobody can justify taking the time to fix it).

Getting rid of the timer tick may be an idea whose time will come in 2.7. The current timer interrupt does not provide the resolution needed for some tasks, but it comes far too often for other applications. Effective power management, in particular, needs to be able to turn off timer interrupts when nothing is happening. So, it has been said, "jiffies must die."

Further discussions took place in unstructured "bar BOFs" and will not be reported on here.


(Log in to post comments)

Kernel Summit: Short topics

Posted Jul 20, 2004 10:32 UTC (Tue) by rjw (guest, #10415) [Link]

When Linus says initramfs stuff will never happen,
did he mean he didn't like it, or that distributors can't be bothered?

If he didn't like it, was there a reason?

Kernel Summit: Short topics

Posted Jul 20, 2004 12:33 UTC (Tue) by jamesm (guest, #2273) [Link]

I think he was kind of joking.

asymmetric multiprocessing?

Posted Jul 20, 2004 11:38 UTC (Tue) by shapr (subscriber, #9077) [Link]

Has there been any progress doing multiprocessing with two different CPUs, rather than just two duplicate CPUs at different speeds?

asymmetric multiprocessing?

Posted Jul 21, 2004 1:43 UTC (Wed) by stuart (subscriber, #623) [Link]

I doubt it; it is terminally bonkers.

Stu.

asymmetric multiprocessing?

Posted Dec 31, 2004 5:34 UTC (Fri) by njhurst (guest, #6022) [Link]

You mean like a PC with a video card with GPU, sound card with DSP and a floating point unit? As each of these components becomes more complex it will need to start maintaining its own resources just like an OS.

Asymmetric multiprocessing is useful in a number of areas, and I suspect it will become more so in the future.

Kernel Summit: Short topics

Posted Jul 20, 2004 21:41 UTC (Tue) by cliffman (guest, #13144) [Link]

So, for testing, how can OSDL get more people looking at the results of tests we run? ( always a question, sigh )

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds