As expected, Linus Torvalds released the 2.6.23-rc1 kernel two weeks after the release of 2.6.22, ending the merge window, "and it has a *ton* of changes as usual for the merge window, way too much for me to be able to post even just the shortlog or diffstat on the mailing list". He noted, "I personally like how 'sendfile' is now totally gone internally, and the kernel now ends up doing all that with splice insted. Good riddance, although we'll obvously end up supporting the old user level interfaces for a long time." Linus went on to summarize the other changes:
"Lots of architecture updates (for just about all of them - x86[-64], arm, alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates (again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, firewire, i2c, you name it).
"Filesystems, VM, networking, ACPI, it's all there. And virtualization all over the place (kvm, lguest, Xen).
"Notable new things might be the merge of the cfs scheduler, and the UIO driver infrastructure might interest some people."
From: Linus Torvalds [email blocked] To: Linux Kernel Mailing List [email blocked] Subject: Linus 2.6.23-rc1 Date: Sun, 22 Jul 2007 14:04:24 -0700 (PDT) Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there. And it has a *ton* of changes as usual for the merge window, way too much for me to be able to post even just the shortlog or diffstat on the mailing list (but I had many people who wanted to full logs to stay around, so you'll continue to see those being uploaded to kernel.org). Lots of architecture updates (for just about all of them - x86[-64], arm, alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates (again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, firewire, i2c, you name it). Filesystems, VM, networking, ACPI, it's all there. And virtualization all over the place (kvm, lguest, Xen). Notable new things might be the merge of the cfs scheduler, and the UIO driver infrastructure might interest some people. Oh, and I personally like how "sendfile" is now totally gone internally, and the kernel now ends up doing all that with splice insted. Good riddance, although we'll obvously end up supporting the old user level interfaces for a long time. So give it all a good whacking, and report back about all the neat new features! Linus
| problem downloading linux-staging tree | 42 minutes ago | Linux general |
| ptrace and big kernel lock | 1 hour ago | Linux kernel |
| SMDK2410 LCD Framebuffer driver | 7 hours ago | Linux kernel |
| Resetting the bios password for Toshiba Laptop | 8 hours ago | Hardware |
| Problem booting a barebone kernel in VMWare | 11 hours ago | Linux kernel |
| IP layer send packet | 15 hours ago | Linux kernel |
| PID to ELF image full path | 17 hours ago | Linux kernel |
| types of kernel | 1 day ago | Linux kernel |
| magical mounts | 2 days ago | Linux kernel |
| Problem in scim in Fedora 9 | 3 days ago | Linux general |
Was swap prefetch merged?
Was swap prefetch merged?
No it wasn't
This links explains what happened to swap prefetch:
http://lkml.org/lkml/2007/7/22/252
Swap prefetch
Why wasn't Con Kolivas work merged?
Con's scheduler
A lot of Con's ideas went into the new scheduler, but his own code had been left out. If you really want his original scheduler you'll have to get the patches and maintain them yourself. I don't think there's any anti-Con conspiracy, just that some kernel people think the CFS is a better implementation.
I don't know the reason why
I don't know the reason why it wasn't merged but unfortunately there's no maintainer for swap prefetch code anymore.
http://lkml.org/lkml/2007/7/22/252
Swap prefetch is not the
Swap prefetch is not the only project that had to wait more than 1.5 years for integration. Reiser4 comes to mind. Hot swappable memory. Tracing. Xen took many years. Ext4 was talked about for years too. The kernel debugger has been around for about 10 years. More than 1.5 years seems rather common for complex kernels features.
With his prior announcement of completely withdrawing from Linux kernel development he might have created a bit of a confusion about the maintenance status of this code. Perhaps he should have made it more clear to the maintainers of the virtual memory code that he would keep maintaining it if his code was merged into the 2.6.23 kernel? Or should he have have passed maintenance of swap prefetch to someone else (were anyone interested) before he left the project for personal and health reasons?
Not equivalent
They're not equivalent. The swap prefetch code was virtually unchanged and stable for 18 months. All it had to do in that time was stay in sync with changes with the vm which were the last "bugs" addressed in the email responded to.
The swap prefetch code was
How about this list of recent fixes:
One round of changes is
One round of changes is nothing like the reiser4 codebase..., it's a small self contained feature and not a huge file system or new architecture. They're totally different things and incomparable.
I dont know. If
I dont know. If swap-prefetch is small and self-contained, that "improvements" patch does not look small.
Nor was reiser4 the only argument given: how about the anti-fragmentation VM patches that have been waiting for integration for eternity? Kdb, LTT, Defrag-ext3? A regular reader of kerneltrap could easily list half a dozen cool-sounding but still pending kernel features - some of them having been on the waiting list for many years.
Linus Torvalds has described himself as feature-happy so generally there's little resistance against shiny new features. New code gets added, old code gets replaced, features get rewritten on an almost daily basis. Con Kolivas is a strong personality, and by pushing for integration in such a way (by suggesting that the whole incident might be part of some conspiracy between kernel devs that resulted in him being shut out permanently) he might have provoked a (conscious or nonconscious) push-back, instead of acceptance.
heuristics for linux kernel
Hello.
My commnet may seem off topic but may be useful anyway. I think that linux kernel should take advantage of the various research that is going on hardawre cache prefetch. Many good ideas have been validated and tested for hardware cache prefetch : for example based on neural networks, bayesian networks, hidden markov models etc... While those ideas may be too heavy to implement in hardware they may be ideal to implement in linux kernel. In particulat they may be useful for swap prefetch. Another that may be useful for VM is to place data that are often accessed together close on disk. When some page is accessed the blocks that are likely to be accessed next may be loaded in just one seek. identifying pages that whose access is correlated is quite similat to the classic clustering problem. This clustering may even be made persistent and stored on disk so as to minimize computation. The same ideas could applied as well for files stored on disk : file that are accessed often may be stored together on disk.
Hello. To make it clear and
Hello.
To make it clear and correct the last sentence of comment should be replaced with "files or disk blocks that are accessed often together should be placed contigously on disk"
NO_HZ merged?
did they merge the dynamic ticks for X86-64 or we will have to wait for newer releases?
CFS not selectable in 23-rc1
How do I test it out?
│ │ [*] Prompt for development and/or incomplete code/drivers
│ │ <*> Anticipatory I/O scheduler │ │
│ │ <*> Deadline I/O scheduler │ │
│ │ <*> CFQ I/O scheduler │ │
│ │ Default I/O scheduler (Anticipatory) ---
Same thing for git3
Same thing for git3
woops, mixed up cpu and io
woops, mixed up cpu and io scheduelers.