Announcement

Collapse
No announcement yet.

2 cores vs. 4 cores in Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    @Frantaylor

    I don't even care what OS it runs, just that it has first-class NFS4 service. I would prefer Linux because I know it best. If there is something that works perfect out of the can, that would be best, but I am willing to fiddle around if I have to. I can see from the discussion here that Linux is not a slam-dunk.
    If you're experiencing similar issue like some of us better don't use Linux it this case.


    Hey kraftman, is this something that you share an interest in? Surely you can tell me if 2 cores is sufficient or if I need 4? And do you know what would be the most stable kernel? I want speed, but data corruption is intolerable.
    I'll recomend 2.6.27, because it's marked as long supported one. If you're going to copy large files XFS should be good (it's known to be good when comes to copying big files, but I never used it too much and I'm not sure if it's as good as some people claim). Maybe better use old Ext3, because it's quite mature, so your data should be safe. When comes to number of cores you should know better, it's your server

    @Energyman

    But since almost nobody with the problem ever complains on lkml it will probably never fixed. So if you see this io-hangs, go to lkml. Thank you.
    There was at least one report, but as far I remember nothing specific. I have no single idea what my report should look like in this case, becasue it's quite strange thing. There's always a chance they'll replace buggy kernel part.

    However, 2.6.31 looks very promising when comes to this issue.
    Last edited by kraftman; 07 August 2009, 04:20 AM.

    Comment


    • #32
      well, describe the symptoms, post the software (kernel, gcc, glbc) versions, hardware, io scheduler used, kernel config. The usual.

      I have solved hang ups with:
      using cfq
      300Hz
      reiser4
      and this:
      echo 1500 > /proc/sys/vm/dirty_writeback_centisecs

      sure, a big copy still can make other disk accesses a bit slow, but I while I am typing, I am copying a 4.4gb big iso from one partition to another... without hangs.

      Comment


      • #33
        Originally posted by energyman View Post
        well, describe the symptoms, post the software (kernel, gcc, glbc) versions, hardware, io scheduler used, kernel config. The usual.

        I have solved hang ups with:
        using cfq
        300Hz
        reiser4
        and this:
        echo 1500 > /proc/sys/vm/dirty_writeback_centisecs

        sure, a big copy still can make other disk accesses a bit slow, but I while I am typing, I am copying a 4.4gb big iso from one partition to another... without hangs.
        Thank you. I'll try 'echo 1500 > /proc/sys/vm/dirty_writeback_centisecs', because other options I have the same (except fs, but it shouldn't matter too much). The best result I achieved was to using anticipatory scheduller and maybe some 'echoes', but I don't remember exactly.

        However, this seems very interesting and optimistic (or not if someone already tried this kernel):

        This regression has been around since about the 2.6.18 timeframe and has eluded a lot of testing to isolate the root cause. The most promising fix is in the VM subsystem (mm) where the LRU scan has been changed to favor keeping executable pages active longer. Most of these symptoms come down to VM thrashing to make room for I/O pages. The key change/commit is ab4754d24a0f2e05920170c845bd84472814c6, "vmscan: make mapped executable pages the first class citizen". For those interested in the...
        Last edited by kraftman; 07 August 2009, 10:04 AM.

        Comment


        • #34
          you might also want to play around with
          /proc/sys/vm/dirty_background_ratio
          /proc/sys/vm/dirty_ratio
          and
          if you are using raid:
          /sys/block/mdX/md/stripe_cache_size
          default is 256 which is incredible slow. I had best results with 4096 and 8192.

          Comment


          • #35
            so, I got my X4 955 today to replace my X2 6000.

            Sooo cool. My box is compiling with -j5 right now, and KDE is a lot more responsive than with two cores and -j3 or 2. Oh - and the cpu is cooler. Same tdp but better powermanagment. I am so glad I did it. 2 cores beat one core. But 4 cores beat 2.

            Comment


            • #36
              File system type issue, not a Linux I/O issue?

              Hi guys,

              I may be able to cast some light onto this?

              I had installed Vmware, onto a partition using ntfs-3g and it was DOG SLOW. I had Vmware running fast as, years ago, on a K6-III+. So, I knew I was not dealing with a hardware issue.

              So, I copied the Vmware image, onto a XFS partition and I was really back in business.

              No I/O issus.

              Note previously, frantaylor in post 6, says XFS was fine.

              Note previously, kraftman Post 19, said he (?) was using "I copied big file from ntfs partition using ntfs-3g."

              Note, the guys that make the free version of the NFFS-3g, also offer a commercial solution, that is .... faster.

              *HTH*

              *BFN*

              GreekGeek :-)

              Comment


              • #37
                Hi,
                I would go for quad core definitely. It's almost the same jump as from single core to dual core.
                Even 1.5ghz dual core is much faster than 2.5 single core in daily usage (except purely single-threaded programs).
                Even dual core can't assure you that when one core is 100% you can use the other as nothing was happening. That's because of x86 architecture.
                However, when you have 4 cores, your chances of faster interactions/response times are getting better, almost twice.
                Definitely quad core, it'll last longer in terms of catching-up to new cpu's.




                Originally posted by GreekGeek View Post
                Hi guys,

                I may be able to cast some light onto this?

                I had installed Vmware, onto a partition using ntfs-3g and it was DOG SLOW. I had Vmware running fast as, years ago, on a K6-III+. So, I knew I was not dealing with a hardware issue.

                So, I copied the Vmware image, onto a XFS partition and I was really back in business.

                No I/O issus.

                Note previously, frantaylor in post 6, says XFS was fine.

                Note previously, kraftman Post 19, said he (?) was using "I copied big file from ntfs partition using ntfs-3g."

                Note, the guys that make the free version of the NFFS-3g, also offer a commercial solution, that is .... faster.

                GreekGeek :-)
                Ntfs-3g has dead slow write times.

                Comment


                • #38
                  now that I have my new quad - go quad. Really, do it. The improvements are easily feelable. Never again will mldonkey make your dual core box sluggish

                  About ntfs-3g. NTFS is not a bad filesystem, but it really is not the fastest horse in the stable. ntfs-3g is like putting cement shoes around its for legs. So it is not only very slow, if you are unlucky it might break a leg or drown.

                  Comment


                  • #39
                    @GreekGeek

                    Note previously, kraftman Post 19, said he (?) was using "I copied big file from ntfs partition using ntfs-3g."

                    Note, the guys that make the free version of the NFFS-3g, also offer a commercial solution, that is .... faster.
                    This is not the case, because when I copy big file on the same Linux' partition the problem remains. However, if it won't be fixed in 2.6.31 I'll probably try XFS. Thanks for your response. There's always possibility some other people aren't affected. Kraftman, she?
                    Last edited by kraftman; 12 August 2009, 10:34 AM.

                    Comment


                    • #40
                      Hi guys,

                      good call energyman, the horse example about captures the speed of ntfs-3g.

                      @ Kraftman, thanks for that clarification. :-)

                      If you Google, you will see find the odd comparison study out there, showing the merrits or otherwise, of different file system types.

                      GreekGeek :-)

                      Comment

                      Working...
                      X