Announcement

Collapse
No announcement yet.

KDE SC 4.7 Release Candidate Hits The Web

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

  • #31
    Originally posted by siride View Post
    free is actually your best bet. System monitor can't be smarter than free because free is as smart as it could be possibly be, at least for this simple case.
    Actually, no. free is pretty dumb compared to system monitor. Quite often, free can't be trusted as much as sysmon.

    Comment


    • #32
      Originally posted by RealNC View Post
      Actually, no. free is pretty dumb compared to system monitor. Quite often, free can't be trusted as much as sysmon.
      And what is it, specifically, that system monitor does that free doesn't do? Obviously, keep in mind the scope of free, which is total system memory usage, and not per-app, for which different tools are obviously better.

      Comment


      • #33
        It has better (more accurate) detection about free memory, buffers, etc.

        Comment


        • #34
          Originally posted by RealNC View Post
          It has better (more accurate) detection about free memory, buffers, etc.
          free uses /proc/meminfo, specifically, the first four values listed there. Do you want to propose that the kernel accounting is incorrect? If so, then how do you propose that system settings does any better? FWIW, I opened up my Ubuntu VM and used GNOME's system monitor and compared what it said to what free said and they matched exactly. I wonder why....

          Comment


          • #35
            The test case I suggested works best in this scenario. I'd even dare to say it's the only correct way of measuring KDE RAM requirements.

            If you want to argue with me, then forward my method to Andrew Morton or Linus Torvalds and hear out what they say.

            Comment


            • #36
              So the KDE RAM usage makes the PC slower or faster?
              There is no point in arguing without considering that!
              Why nobody is measuring speed? Oh, I see, because performance/responsiveness is more difficult to measure than looking at a single number and yelling "there, RAM wasted!"

              But, is it better to have RAM storing pixmaps, app data, or whatever KDE stores, or is it better to leave that RAM for disk cache, and let the system manage it?

              I think that, given the choice, it'll be almost always better to let the app decide what's better to store. After all, the app knows best what's most urgent to the user.

              Comment


              • #37
                Originally posted by DeiF View Post
                So the KDE RAM usage makes the PC slower or faster?
                There is no point in arguing without considering that!
                Why nobody is measuring speed? Oh, I see, because performance/responsiveness is more difficult to measure than looking at a single number and yelling "there, RAM wasted!"

                But, is it better to have RAM storing pixmaps, app data, or whatever KDE stores, or is it better to leave that RAM for disk cache, and let the system manage it?

                I think that, given the choice, it'll be almost always better to let the app decide what's better to store. After all, the app knows best what's most urgent to the user.
                also: unused RAM = wasted RAM
                I have 8GB of RAM and almost all the time 2GB or more aren't used. I would be happy if KDE starts using more RAM to become more responsive.

                Comment


                • #38
                  Originally posted by droste View Post
                  also: unused RAM = wasted RAM
                  I have 8GB of RAM and almost all the time 2GB or more aren't used. I would be happy if KDE starts using more RAM to become more responsive.
                  What on earth is KDE going to do with 8GB RAM

                  Comment


                  • #39
                    Originally posted by birdie View Post
                    The test case I suggested works best in this scenario. I'd even dare to say it's the only correct way of measuring KDE RAM requirements.

                    If you want to argue with me, then forward my method to Andrew Morton or Linus Torvalds and hear out what they say.
                    You refuse to explain this "advanced" algorithm which incidentally can't possibly do better than free because free already does the best possible job of measure RAM usage. The division is very simple: RAM either belongs to buffers, cache, or is used by programs/the kernel actively. The kernel necessarily can easily know how much is in any of these because the datastructures are known and the kernel has to track its memory allocations anyway for MM purposes. If you want to be a little more fine-grained, you could subtract out vmalloc allocations and the size of the kernel text and ro data segments, but those last two are pretty small in the grand scheme of things (a few megs).

                    The alternative is to go through each process and get the total memory used, then try to figure out what's shared and then try to subtract out buffers and caches (which you get from meminfo anyway) and you will end up with something less accurate that takes longer. I'm not sure why that would be a better way because figuring out memory sharing is a real pain in the ass. It's necessary if you want to find out per-process memory usage, but free doesn't even try to do that anyway, so it's moot for this discussion.

                    Comment


                    • #40
                      Originally posted by RealNC View Post
                      What on earth is KDE going to do with 8GB RAM
                      I don't want KDE to use all of the 8GB. That would be really bad

                      Comment


                      • #41
                        Originally posted by siride View Post
                        And what is it, specifically, that system monitor does that free doesn't do? Obviously, keep in mind the scope of free, which is total system memory usage, and not per-app, for which different tools are obviously better.
                        It does something like this:

                        The process akonadi_maildis (with pid 1215) is using approximately 4.5 MB of memory.
                        It is using 3.8 MB privately, and a further 16.2 MB that is, or could be, shared with other programs.
                        Dividing up the shared memory between all the processes sharing that memory we get a reduced shared memory usage of 752.0 KB. Adding that to the private usage, we get the above mentioned total memory footprint of 4.5 MB.
                        However, when comes to total memory usage maybe you're right.

                        Comment


                        • #42
                          Originally posted by Jimbo View Post
                          Sometime ago, I filled a bug about akonadi / nepomuk *brutal* memory usage on kde, of course I obtained no response (well, I was expecting that). If you are concerned about kde memory usage , you could vote this bug:

                          https://bugs.kde.org/show_bug.cgi?id=262981

                          As birdie has already pointed , opening a mysql instance to waste 200 - 300 MB of memory is just not the best idea to implement on a DE.
                          Actually these bugs have been fixed in 4.6.x series. At least in Debian. My akonadi + instances eat < 5 (some akonadi services each ~900KB) MBs of RAM. I can pay that price for the ability of searching my documents.

                          I personally dug that bug and they believed that the bug is in indexer but while sorting out another bug, it magically disappeared. I don't know which commit or when but it vanished. I personally use my work computer w/ KDE and suffered from it for months. Currently akonadi services and mysql just sits there silently and peacefully.

                          OTOH, Akonadi should use virtuoso which really eats ~190MB, not MySQL.

                          Cheers.

                          Comment


                          • #43
                            Originally posted by kraftman View Post
                            It does something like this:



                            However, when comes to total memory usage maybe you're right.
                            If you read my post, not only will you see that I talked about that algorithm, but I also said that it was not a good way to get total memory usage, or at least no better than just using the summary from /proc/meminfo.

                            Comment


                            • #44
                              Originally posted by siride View Post
                              If you read my post, not only will you see that I talked about that algorithm, but I also said that it was not a good way to get total memory usage, or at least no better than just using the summary from /proc/meminfo.
                              Yes, but I don't know if system monitor uses this way to count the total memory usage.

                              Comment


                              • #45
                                Originally posted by kraftman View Post
                                Yes, but I don't know if system monitor uses this way to count the total memory usage.
                                As it turns out, it literally reads /proc/meminfo. Check the source (from http://quickgit.kde.org/?p=kde-works...Linux/Memory.c line 103):

                                Code:
                                int updateMemory( void )
                                {
                                  /**
                                    The amount of total and used memory is read from the /proc/meminfo.
                                    It also contains the information about the swap space.
                                    The 'file' looks like this:
                                 
                                    MemTotal:       516560 kB
                                    MemFree:          7812 kB
                                    MemShared:           0 kB
                                    Buffers:         80312 kB
                                    Cached:         236432 kB
                                    SwapCached:        468 kB
                                    Active:         291992 kB
                                    Inactive:       133556 kB
                                    HighTotal:           0 kB
                                    HighFree:            0 kB
                                    LowTotal:       516560 kB
                                    LowFree:          7812 kB
                                    SwapTotal:      899632 kB
                                    SwapFree:       898932 kB
                                    Dirty:            2736 kB
                                    Writeback:           0 kB
                                    Mapped:         155996 kB
                                    Slab:            73920 kB
                                    Committed_AS:   315588 kB
                                    PageTables:       1764 kB
                                    ReverseMaps:    103458
                                   */
                                 
                                  int fd;
                                  size_t n;
                                 
                                  if ( ( fd = open( "/proc/meminfo", O_RDONLY ) ) < 0 ) {
                                    print_error( "Cannot open \'/proc/meminfo\'!\n"
                                                 "The kernel needs to be compiled with support\n"
                                                 "for /proc file system enabled!\n" );
                                    return -1;
                                  }
                                 
                                  n = read( fd, MemInfoBuf, MEMINFOBUFSIZE - 1 );
                                  if ( n == MEMINFOBUFSIZE - 1 || n <= 0 ) {
                                    log_error( "Internal buffer too small to read \'/proc/meminfo\'" );
                                    close( fd );
                                    return -1;
                                  }
                                 
                                  close( fd );
                                  MemInfoBuf[ n ] = '\0';
                                  Dirty = 1;
                                 
                                  return 0;
                                }

                                Comment

                                Working...
                                X