Speeding Up The Linux Kernel With Transparent Hugepage Support

[squirrl]

oh no

I tried the tty trick on the 2.6.32 kernel.

Copying a 9 Gig file from my desktop to my home directory resulted in only after 30 seconds a non-responsive experience.


I went and compiled the 2.6.36 kernel myself. I didn't try the tty haxoring. But my same test resulted in the same experience.


What I did do was install the CK BFS patches for 2.6.36. Testing my 9 GB copy again I had desktop responsiveness which was pretty decent.

Seems to me taking the staircase is a lot better than the car pooling solutions.

[chronniff]

I have also been using 2.6.36 with the ck bfs patches, and I agree that it still does at least equally in terms of responsiveness. Seems to me that the mainline developers have been letting their pride get in the way considering the BFS patch has been out for what seems like a very long time now (over a year?) and they have yet to commit any real changes in terms of responsiveness into to the kernel.....however I am curious to test out this new patch and see where it takes me

[FunkyRider]

Copying a 9G file you are mostly I/O bounded, it merely has anything to do with CPU/RAM. A better I/O scheduler might give you far better result.

[Elv13]

We are not talking about I/O performances, we are talking about X freezing with I/O intensive task. DMA operation should -never- slow down anything else, they are DMA...

[Obscene_CNN]

Ummmm ......

Actually this thread is about the Transparent Hugepage support patch. It will make some apps run faster but I don't think it will make hardly any difference in X freezing with I/O intensive task.

[yoshi314]

i wonder if that will affect gcc performance. when dealing with complex c++ code it gets really memory intensive.

[Xanbreon]

I have also been using 2.6.36 with the ck bfs patches, and I agree that it still does at least equally in terms of responsiveness. Seems to me that the mainline developers have been letting their pride get in the way considering the BFS patch has been out for what seems like a very long time now (over a year?) and they have yet to commit any real changes in terms of responsiveness into to the kernel.....however I am curious to test out this new patch and see where it takes me

Try BFS (cpu sced) and BFQ (io sched), I find them far better then CFS (cpu sced - with and without these new magic patches) and CFQ (io sched).

Things dont seem to lock up at all, even under stupid load, eg -j64 kernel builds, and copying huge chunks around (even to NTFS partitions - don't ask).

([email protected] - stock - 8gig of ram - so its good but not brand new)

[kebabbert]

We are not talking about I/O performances, we are talking about X freezing with I/O intensive task. DMA operation should -never- slow down anything else, they are DMA...

Is it that bad in Linux? You must be joking?

[Xanbreon]

Is it that bad in Linux? You must be joking?

Try copying a 9gig file across HDD's in windows, then try todo something CPU/IO heavy, watch as explorer crashes or everything slows down to 386 speeds.

This of cause doesnt always happen, but I have seen it often enough with XP/Vista/7.

I think window's problem is that it spends to much time trying to guess how long its going to take, and even then it never gets it right

[evolution]

Personlly, since the latest test updates of BFS, I'm using 2.6.36.1 but with the most recent CK "test" patches, because I found the "automatic group scheduler" (AGS) patch a slower than BFS with very heavy I/O loads (eg. when I was moving large files between different partitions and at the same time browsing the internet, the page loading was very slow (but not that much, in comparision with BFS); even in more slow I/O loads, these "AGS" patches were moving the files "by segments", while on BFS the files were being moved more "smoothly").

These new patches you put there, currently only work with 2.6.37-rc kernels (I tried to create a BFS "testing" + Huge Transparent Page patched kernel, but it was giving me failed non-reversible hunks...)

Cheers!