The 2.6.38 kernel is out
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.
Posted Mar 15, 2011 13:50 UTC (Tue)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Mar 15, 2011 19:59 UTC (Tue)
by coriordan (guest, #7544)
[Link] (1 responses)
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.)
Posted Mar 16, 2011 13:44 UTC (Wed)
by coriordan (guest, #7544)
[Link]
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.
Posted Mar 15, 2011 16:35 UTC (Tue)
by gmatht (subscriber, #58961)
[Link] (3 responses)
Posted Mar 15, 2011 18:29 UTC (Tue)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Mar 15, 2011 19:05 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link]
(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.
Posted Mar 17, 2011 2:43 UTC (Thu)
by gmatht (subscriber, #58961)
[Link]
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.
Posted Mar 15, 2011 17:58 UTC (Tue)
by jetm (subscriber, #61129)
[Link] (3 responses)
Maybe this version could become the next Long-Term Stable like replacement for 2.6.32.x Version.
Posted Mar 15, 2011 19:23 UTC (Tue)
by gregkh (subscriber, #8)
[Link] (2 responses)
And no, it's not going to be, just to answer that question, there is
Posted Mar 16, 2011 10:50 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Mar 16, 2011 14:45 UTC (Wed)
by gregkh (subscriber, #8)
[Link]
Posted Mar 16, 2011 20:24 UTC (Wed)
by GhePeU (subscriber, #56133)
[Link] (1 responses)
$ while true; do ls -s test.ts; sleep 1s; done
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.
Posted Mar 17, 2011 6:52 UTC (Thu)
by dark (guest, #8483)
[Link]
All in all, it would have been nice if the ftpd had had some kind of hook to run a script after an upload :)
The 2.6.38 kernel is out
anyone here notice better performance?
anyone here notice better performance?
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?
Btrfs LZO support: save time as well as space?
Btrfs LZO support: save time as well as space?
Userspace and Kernel space policies.
The future replacement for Long-Term Stable (2.6.32.x) version?
The future replacement for Long-Term Stable (2.6.32.x) version?
said anything that would indicate this would be the case?
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?
The future replacement for Long-Term Stable (2.6.32.x) version?
in the future as "long-term".
The 2.6.38 kernel is out
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
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.
The 2.6.38 kernel is out