1. Куча / Говнокод #23651

    0

    1. 1
    2. 2
    3. 3
    https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf
    
    http://lkml.iu.edu/hypermail/linux/kernel/1612.1/00383.html

    x86-64 is currently limited to 256 TiB of virtual address space and 64 TiB
    of physical address space. We are already bumping into this limit: some
    vendors offers servers with 64 TiB of memory today.

    To overcome the limitation upcoming hardware will introduce support for
    5-level paging. It is a straight-forward extension of the current page
    table structure adding one more layer of translation.

    It bumps the limits to 128 PiB of virtual address space and 4 PiB of physical address space.
    This "ought to be enough for anybody" Â.

    https://imgs.xkcd.com/comics/supported_features.png

    Запостил: 3.14159265, 11 Января 2018

    Комментарии (79) RSS

    • i am a very baaaad boy
      Ответить
    • Никогда не было и вот опять.
      Ответить
    • x86-64 говно, переходим обратно на IA32
      Ответить
      • i am a very baaaad boy
        Ответить
      • >x86-64 говно, переходим обратно на IA32

        Ну да. Пару лет назад на ГК уже предлагал такую идею.

        Использовать 32ю-битную адресацию в x64.
        Вот прям сейчас на моём десктопе ни одному из работающих процессов не нужно более 4х гиг памяти.

        Если даже в 2к18 хватает 32 бит на процесс, зачем тогда использовать 64-битные указатели адреса?
        В любом случае все адреса уже лет 30 как виртуальные, и не соотвествуют физическим.
        За эти годы намазали столько абстракций что пришлось пилить TLB для ускорения вычисления реальных адресов.

        Можно уменьшить все массивы с указателями, все таблицы виртуальных функций, более плотно забивать кеши.

        При том я предлагал сиё еще до всяких meltdownов. Если каждый процесс заточён в матрице 4гиг своей виртуальной памяти, как он в принципе может смотреть в память чужого процесса?

        Любое переполнение 32-битного адреса простоприведёт к враппингу и не приведёт к плачевным итогам. Но нет, нужно выдумывать запредельно сложные костыли и прочую ASLR-питушню.



        В моей практике даже на серверах процессы занимающие более 4х гиг были довольно редки. И обычно мы с таким боролись.
        Поскольку на таких больших кучах, становились болезненными существенные задержки от stop-the-world.
        Ответить
        • А на моей практике процессы занимающие десятки гигабайт совершенно не редки. Хорошо, что я пишу на языке без сборщика мусора, а ты не проектирует процессоры.

          П.С.: 32-разрядные оси тоже уязвимы, на сколько я понимаю.
          Ответить
          • >Хорошо, что я пишу на языке без сборщика мусора, а ты не проектирует процессоры.

            Хм, даже Дональд Кнут соглсен с моей точкой зрения.
            A Flame About 64-bit Pointers

            It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only waste half the memory, they effectively throw away half of the cache.

            The gcc manpage advertises an option "-mlong32" that sounds like what I want. Namely, I think it would compile code for my x86-64 architecture, taking advantage of the extra registers etc., but it would also know that my program is going to live inside a 32-bit virtual address space.

            Unfortunately, the -mlong32 option was introduced only for MIPS computers, years ago. Nobody has yet adopted such conventions for today's most popular architecture. Probably that happens because programs compiled with this convention will need to be loaded with a special version of libc.
            Ответить
            • x32 ABI есть, но он не очень взлетел.
              Ответить
              • i am a very baaaad boy
                Ответить
              • >x32 ABI есть

                Да знаю, но оно ж ABI, там надо всё пересобирать/перелинковывать.

                И еще там есть неприятный нюанс: ассемблерные вставки могут сломаться и ломаются.
                А без них...

                Короче потому и не взлетел, что надо софт портировать и вдовесок к lib и lib64 тащить libx32
                Ответить
        • Т.е. мы посылаем нахуй тех, кому нужно больше 4 гига?
          Ответить
          • Нет.

            Вот как например реализованы те же transparent huge pages? Мы не посылаем нахуй тех кому нужны страницы по 2 и 4 Мб, но при этом поддерживаем странички по 4Kb.
            Ответить
        • Ну, по сути, так оно и есть - программы, которым не нужно 64 бита, спокойно можно делать 32-хбитными, и они работают по 32-х битной осью.
          А вот обратное... скажем, мне понадобилась 64-битная программа (да тот же бинарь Qt под Linux) - так пришлось систему переставлять. Может, пусть луше будет 64-битное единообразие?
          Ответить
        • Я писал программы, использующие десятки гигабайт виртуальной памяти.
          man mmap
          Ответить
          • i am a very baaaad boy
            Ответить
          • >Я писал программы, использующие десятки гигабайт виртуальной памяти.

            Это повод для гордости?
            Ответить
            • > Это повод для гордости?

              Это факт. Маппинг файлов в виртуальную память — очень полезная техника, у которой практически нет алтернатив. Алсо,
              https://github.com/yandex/mms
              Ответить
              • В конце концов я же не говорю что процессы с адресацией больше 4х гиг не нужны.

                Я говорю что большинству программ до сих пор хватает 32-разрядных адресов. Зачем нужны 64 указатели - большой вопрос.

                >yandex/mms
                Да это всё узкая серверная питушня и ЯНДЕКСОПРОБЛЕМЫ, думаю найдётся тот кто скажет что ему мало и петабайта виртуальной памяти:

                > x86-64 is currently limited to 256 TiB
                Ответить
    • ЯННП
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • i am a very baaaad boy
      Ответить
    • У тебя бота заклинило, Стертор.
      Ответить

    Добавить комментарий