Linux Kernel Performance Bottlenecks Spotted By Mold Developer

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

  • Anux
    replied
    Originally posted by schmidtbag View Post
    Most of what I said is not limited to disk bandwidth. There's quite a lot of overhead to collect the necessary information and to communicate over the various busses.
    You mean on the hardware side? I doubt it, any recent hardware should have no problem to do such operations in a few ms. The only thing could be file system or driver/kernel related bugs.
    You could also conclude hat from the description, that it is faster if the file exists. Hardware doesn't care about that, it only writes data.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by stiiixy View Post

    Probably out of context considering SSD is the theme, but SDCard.
    True, but that's sort of like pointing to SATA as a reason to keep a first-generation NVMe drive around for testing.

    If you want to choke things down, there are plenty of ways using modern technology, rather than old stuff that's harder to replace if it dies. (Hell, I haven't tried it, but you could probably simulate ancient storage technology performance by hitting NewEgg's "Under 5400RPM" filter and pairing what you find with a $3 SATA-to-IDE and a $3 IDE-to-SATA adapter off AliExpress. (Assuming you can't just simulate it in software using something like hdparm.)

    Leave a comment:


  • AdrianBc
    replied
    Originally posted by Wielkie G View Post
    The first two points are nothing new as he has described them already since the very first version of mold (if I recall correctly). It is just the first time this has been brought forth to the kernel developers.

    I cannot speak about the last point though. It might be a more recently found issue.


    For the last point, it seems that there are several solutions that he has not tried.

    For example, each linker process can attach a shared memory segment with "shmat".

    The number of processes attached to the shared memory segment can be obtained with "shmctl".
    Also with "shmctl", the segment can be marked to be deleted when the last process detaches from it.

    When a process exits, it is automatically detached from any such shared memory segment.

    This provides exactly the behavior requested by him, which enables the detection of how many linker processes are active, so Linux does not need any change from this point of view. These are ancient system calls belonging to UNIX System V IPC, so they are not widely known today.


    Last edited by AdrianBc; 30 November 2024, 08:42 AM.

    Leave a comment:


  • stiiixy
    replied
    Originally posted by ssokolow View Post

    And, as far as I know, those things are SATA3, not SATA1, just like the cheap WD Blue SSDs in my mother's old laptop, my hand-me-down laptop, and the hand-me-down 2012 HP prebuilt that I turned into a "game console but not a console". Hell, the 2011 Athlon I used to be using does SATA3 and has a WD Blue I'll probably repurpose as I slowly part it out.

    There's no reason aside from "test platform for preventing minimum requirements creep" for a developer to be using something that drives the link at 1.5Gbits instead of 6Gbits in this day and age.
    Probably out of context considering SSD is the theme, but SDCard.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by coder View Post
    No web comic I've seen holds a candle to XKCD.
    Oglaf is pretty good.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Guiorgy View Post

    I'm using Samsung PRO SATA... 😅
    And, as far as I know, those things are SATA3, not SATA1, just like the cheap WD Blue SSDs in my mother's old laptop, my hand-me-down laptop, and the hand-me-down 2012 HP prebuilt that I turned into a "game console but not a console". Hell, the 2011 Athlon I used to be using does SATA3 and has a WD Blue I'll probably repurpose as I slowly part it out.

    There's no reason aside from "test platform for preventing minimum requirements creep" for a developer to be using something that drives the link at 1.5Gbits instead of 6Gbits in this day and age.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by Anux View Post
    On an SSD this should take a few ms not a whole second.
    Most of what I said is not limited to disk bandwidth. There's quite a lot of overhead to collect the necessary information and to communicate over the various busses.

    Leave a comment:


  • coder
    replied
    Originally posted by geerge View Post
    Everybody Loves Raymond is alright if you like cheesy 90's sitcoms, mostly a vehicle for Ray Romano but the other regulars were decent. Nothing I'd go out of my way to watch, but if I owned a TV and it was on when it got turned on it might stay on until the ad break.
    Thanks for filling in that detail.

    As for Everybody Loves Eric Raymond, I don't recall it usually being super funny or insightful, but it's certainly possible I was missing some context. Interesting enough to look at, every now and then. No web comic I've seen holds a candle to XKCD.

    Leave a comment:


  • ahrs
    replied
    Originally posted by stormcrow View Post

    Because the goal of MOLD is performance at all costs. That means you make sacrifices elsewhere others may not be willing to make, including instruction code quality, size, potentially even sacrifice security considerations.
    There are also some instances where Mold fails to link correctly because of this lofty goal. I use Mold by default on my Gentoo system but occasionally I end up having to
    Code:
    env LDFLAGS="$(portageq envvar LDFLAGS | sed 's|mold|lld|g')" emerge …
    or bfd, or gold, etc, if something has issues.

    Leave a comment:


  • Guiorgy
    replied
    Originally posted by Anux View Post
    Dude, do you really think a dev today is using an SATA1 SSD?
    I'm using Samsung PRO SATA... 😅

    Leave a comment:

Working...
X