The 2.6.38 kernel is out [LWN.net]

Linus has announced the release of the 2.6.38 kernel. "As to the "big picture", ie all the changes since 2.6.37, my personal favorite remains the VFS name lookup changes. They did end up causing some breakage, and Al has made it clear that he wants more cleanups, but on the whole I think it was surprisingly smooth." Other significant changes in 2.6.38 include transparent hugepage support, per-session group scheduling, a number of Btrfs improvements, and more. The always excellent KernelNewbies.org page has all the details.

to post comments

The 2.6.38 kernel is out

Posted Mar 15, 2011 13:50 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

When it comes to performance improvements this looks like the best kernel in *ages*. It might even compensate for the increasing icache hit of the kernel over the last few years ;}

anyone here notice better performance?

Posted Mar 15, 2011 19:59 UTC (Tue) by coriordan (guest, #7544) [Link] (1 responses)

I've been using it since .38-rc7 but I haven't noticed the improvement.

Does anyone here notice better performance?

When the patch was announced, the example everyone gave was that interactivity was better while compiling a kernel. I only compile a kernel or similar about once a year. Are there any more day-to-day tasks that expose this performance improvement?

(I grabbed .38-rc7 because I needed a driver.)

anyone here notice better performance?

Posted Mar 16, 2011 13:44 UTC (Wed) by coriordan (guest, #7544) [Link]

Of course, the performance increase is still great, even if no one noticed it. I mean, when 'find' finishes, I never say "Hey, that seemed 30% faster than previously". But faster execution surely leads to me being happier.

The driver I needed works fine.

The only problem I have is that X has started getting messed up since I upgraded to .38, but I also upgraded my X packages a few days earlier so it could be either. I'll upgrade my Linux again after a few point releases.

Btrfs LZO support: save time as well as space?

Posted Mar 15, 2011 16:35 UTC (Tue) by gmatht (subscriber, #58961) [Link] (3 responses)

The feature I am most excited about is the support in btrfs for lzo[1]. The Eeepc 701 had only 4GB of storage so it needs all the space it can get, and compression really helps. However netbooks don't have great CPU performance either gzipping everything seems not to be great for performance. However, the CPU on the Eeepc 701 can decompress lzo twice as fast as it can read data from it's SSD so compressing /usr and the other mostly static directories with lzo should save time as well as space for many loads.

Btrfs LZO support: save time as well as space?

Posted Mar 15, 2011 18:29 UTC (Tue) by epa (subscriber, #39769) [Link] (2 responses)

I'm wondering whether the next version will have automatic LZO compression that switches on when the CPU is fast enough, and the disk slow enough, that it's faster to compress data and write it than to write it uncompressed.

Btrfs LZO support: save time as well as space?

Posted Mar 15, 2011 19:05 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

This is a dynamic problem, and so probably not well-suited to automation

(of course the kernel does automate certain things which are similarly difficult, but that's generally out of necessity)

It's dynamic because right now I may be watching a movie and need all the CPU to do that, and then later I may be trying to perform a git clone before going to bed and want maximum filesystem throughput, and those two possibilities call for different behaviour regarding trading bandwidth for CPU.

If I set a switch manually I can at least blame /myself/ when one of these activities is unsatisfying. If it happens automatically I will be sure to blame the kernel maintainers, particularly when some inevitable compromise manages to achieve the worst of both worlds and make my movie unwatchable and my git clone still take too long.

Userspace and Kernel space policies.

Posted Mar 17, 2011 2:43 UTC (Thu) by gmatht (subscriber, #58961) [Link]

To a limited extent this can be implement in user space. At a most basic level, if we are using a multicore system and a single core can easily saturate the SSD then the installer suggesting compression seems a safe bet (e.g. on my Core2Duo can compress lzo compresses at 44MB/s while a typical USB stick can only write at 10MB/s). It seems that somewhat more dynamic polices could also be implemented in userspace, e.g. using remount,compress.

On obvious policy is, only compress using idle cycles. This would mean that a standard IO bound task writing compressible data should run faster while not affecting the performance of CPU bound tasks (assuming decompression time is negligible). In some cases it should also give better write performance than either compress or no_compress E.g. when the CPU can compress at 30MB/s and the media can write at 30MB/s, then we could write 30MB/s of data compressed down to (say) 17MB/s and 13MB/s of uncompressed data, for a total of 43MB/s.

If the user manually selects such a policy they can't blame the kernel devs if it is not suitable :). Whether that complexity is worthwhile is another issue.

The future replacement for Long-Term Stable (2.6.32.x) version?

Posted Mar 15, 2011 17:58 UTC (Tue) by jetm (guest, #61129) [Link] (3 responses)

Maybe this version could become the next Long-Term Stable like replacement for 2.6.32.x Version.

The future replacement for Long-Term Stable (2.6.32.x) version?

Posted Mar 15, 2011 19:23 UTC (Tue) by gregkh (subscriber, #8) [Link] (2 responses)

Why would .38 become a long term replacement for .32? Has anyone
said anything that would indicate this would be the case?

And no, it's not going to be, just to answer that question, there is
currently no known plan to replace .32 with a newer "longterm" kernel
in the near future, sorry.

The future replacement for Long-Term Stable (2.6.32.x) version?

Posted Mar 16, 2011 10:50 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I'm curious, what version of Linux will be on long-term support next? Something like .42?

The future replacement for Long-Term Stable (2.6.32.x) version?

Posted Mar 16, 2011 14:45 UTC (Wed) by gregkh (subscriber, #8) [Link]

There are no plans at this time to pick up any specific kernel version
in the future as "long-term".

The 2.6.38 kernel is out

Posted Mar 16, 2011 20:24 UTC (Wed) by GhePeU (subscriber, #56133) [Link] (1 responses)

Be careful if you use XFS, block allocation apparently changed, and the size of growing files as reported by 'ls -s' or 'du -sk' doesn't grow linearly anymore:

$ while true; do ls -s test.ts; sleep 1s; done
0 test.ts
0 test.ts
0 test.ts
576 test.ts
576 test.ts
1088 test.ts
2112 test.ts
2112 test.ts
4160 test.ts
4160 test.ts
4160 test.ts
8256 test.ts
8256 test.ts
8256 test.ts
8256 test.ts
8256 test.ts
8256 test.ts
16448 test.ts
16448 test.ts
16448 test.ts
16448 test.ts
16448 test.ts
16448 test.ts

This broke a couple of scripts I was using on a machine who doubles as DVR to detect if tzap was still recording (I was checking every two seconds if the filesize was changing) and to restart it. When I came home I found 30 3-4MB files instead of an hour long recording.

The 2.6.38 kernel is out

Posted Mar 17, 2011 6:52 UTC (Thu) by dark (guest, #8483) [Link]

When I had to do something similar to collect files uploaded to an ftp server, I used lsof to check if the ftpd still had the files open. That worked well, but it wasn't the whole story because ftp transfers can be interrupted and then resumed. Fortunately the files were all zip archives, so when the transfer appeared to be done I could do an integrity check to see if we got the whole file.

All in all, it would have been nice if the ftpd had had some kind of hook to run a script after an upload :)