Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 43

Thread: Speeding Up The Linux Kernel With Transparent Hugepage Support

  1. #11
    Join Date
    Aug 2009
    Location
    south east
    Posts
    342

    Default 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.

  2. #12
    Join Date
    Jan 2010
    Posts
    105

    Default

    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

  3. #13
    Join Date
    Aug 2007
    Posts
    437

    Default

    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.

  4. #14
    Join Date
    Oct 2008
    Posts
    60

    Default

    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...

  5. #15
    Join Date
    May 2009
    Location
    Richland, WA
    Posts
    134

    Default

    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.

  6. #16
    Join Date
    Sep 2006
    Location
    PL
    Posts
    910

    Default

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

  7. #17
    Join Date
    Mar 2010
    Posts
    30

    Default

    Quote Originally Posted by chronniff View Post
    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).

    (q6600@2.4ghz - stock - 8gig of ram - so its good but not brand new)

  8. #18
    Join Date
    Nov 2008
    Posts
    418

    Default

    Quote Originally Posted by Elv13 View Post
    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?

  9. #19
    Join Date
    Mar 2010
    Posts
    30

    Default

    Quote Originally Posted by kebabbert View Post
    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

  10. #20
    Join Date
    Oct 2010
    Posts
    257

    Default

    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!

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •