MMF, разделяемая память и все все все

Kernel architecture questions
  • Ghost
    Я понимаю конечно что ты специалист неплохой как минимум, но мог бы ты нам непрофесионалам объяснить что сие имелось ввиду?

    Даже то что наработано не используется, но переиодически люди начинают вопить:
    1) Лучше микроядро
    2) Лучше Си
    3) Лучше портировать...
    При этом никто этим заниматься из кричащих не собирается.
  • Файлы проецируемые в память, это концепция работы с файлами, суть которой в том что работа с файлом организуется как с массивом в памяти. Писатель из меня хреновый, поэтому перенаправляю к Рихтеру, там все подробно рассписано, часть относящуюся в особенностям реализации в Win можно пропустить, для понимания она не нужна.
  • Ghost
    Так, в кратце ознакомился, но вот что меня смущает - реализация очень смахивает на реализацию файла подкачки для виртуального адресного пространства. Мне так кажется не все так просто, хотя подход надо признать интересный и перспективный. Но я лично его не осилю с большой вероятностью. И раз уж ты предложил идею - возникает вопрос на миллион: You ready?
  • Ghost
    MMF в данном контексте ни при чём (файлы в памяти имеют совершенно не такой вид, как на диске - как исполняемые, так и библиотеки). А вот разделение памяти между разными экземплярами одной и той же загруженной библиотеки пригодилось бы.
    Ушёл к умным, знающим и культурным людям.
  • diamond почему же не такой? если ещё и внести в головы прикладных разработчиков идею о разделении кода и данных, на сегментах кода можно экономить память, а если данные не модифицируются то и на сбросе кеша можно попробывать экономить. Ну а с библиотеками, с учетом того что вероятность их многократной загрузки намного больше чем приложений - само собой пригодится. Ну и размышляя далее, таким образом несложно получить разделяемую память...
  • diamond wrote:А вот разделение памяти между разными экземплярами одной и той же загруженной библиотеки пригодилось бы
    Здесь нужна концепция какая-то. Раз память единая, значит единый адрес для всех процессов.
    В том числе и для сегментов данных (этой же либы), которые как раз и НЕ должны разделяться всеми процессами.
    И где интересно такая область логических адресов расположена ???
    Если в нижних 2-х гигах, то это может явиться неожиданностью для процессов не использующих эту либу... Ну вроде бы память и есть, а ее на самом деле уже и нет...
    Это для всех либов так, или только для некоторых ???

    Ну и еще куча аналогичных вопросов, постановочного характера.
    Определенность в этих вопросах -- и можно было бы приступать к делу.
    Но вас же разговорить - не самая тривиальная задача. Каждый почему-то боится высказать идею, у которой есть риск оказаться неправильной :wink:
    Ей богу, такой стиль совместной разработки - не самый оптимальный, ИМХО.
    Ну вот и имеем, не более чем "хорошо бы" :)
  • ЗЫ: кстати делал где-то (сразу и не найду): Технология MMF может явиться "переходником" между 32-х битными стримами, и "шибко длинными" реальными файлами.
    Ну типа выкидывается окно из этого файла, с которым ты уже можешь работать с 32-х битными библиотечными ф-ями.
  • Ну тут несколько подходов, например как делается вроде в ELF, весь код библиотеки не привязан к адресам, таким образом его можно пристегивать к любым адресам процесса, просто динамически выделяея в контексте процесса необходимую память, ни о каких "верхних 2Гб" думать не надо. Плох вариант тем что за счет не привязанности кода к адресам, получаем много лишних обвесок (хотя по сути они нужны для глобальных переменных и call`ов).
    Другой вариант - твои нижние 2 гига, почему нет? или у нас есть приложения использующие столько памяти?
  • Ghost wrote:Плох вариант тем что за счет не привязанности кода к адресам, получаем много лишних обвесок (хотя по сути они нужны для глобальных переменных и call`ов)
    И еще тем, что замахаешься кодить в эдаком стиле :)
    Ghost wrote:Другой вариант - твои нижние 2 гига, почему нет?
    Ну не совсем мой :)
    Мне пока больше нравятся как раз верхние 2Г. Ну типа: хип ядра растет снизу (с "2Г" - вверх), а "системные либы" лепятся сверху (от 4Г - вниз), и имееют одинаковые адреса для всех процессов и для ядра
    Тоже спрошу - почему нет ???
    И кстати, следует ЛИ делить либы на "системные", и "общечеловеческие" ???

    Кстати, было где-то на этом форуме: у чела не прилепилась в винде какая-то системная либа, типа -- место уже занято...
  • Ghost
    Ещё раз: приложения и библиотеки на диске имеют совершенно другой вид, чем в памяти независимо от того, выделены сегменты кода и данных или нет. Потому что ядро умеет грузить kpack'ованные приложения.
    Похоже, ты путаешь концепцию memory-mapped files и разделяемую память. Это совершенно независимые вещи. То, что можно спроецировать одну и ту же физическую страницу с кодом в адресное пространство двух разных процессов, никак не связано с тем, что можно привязать страницу в памяти к странице на диске.
    Galkov
    Делать допущение
    Раз память единая, значит единый адрес для всех процессов.
    совершенно не обязательно. Одну и ту же физическую страницу можно отобразить на совершенно разные логические адреса.
    Насчёт проблем с тем, что в библиотеке код может быть привязан к адресу загрузки библиотеки, - есть несколько возможных решений. В Linux принято делать в разделяемых библиотеках position-independent code, что означает лишний код и лишнюю задержку в каждой функции (или, по крайней мере, в каждой "торчащей наружу" функции) для получения загруженной базы и, что ещё хуже, резервирование одного регистра под эту базу (учитывая, что в x86 регистров общего назначения всего 7, это актуально). В Windows принято в разделяемых библиотеках указывать предпочтительный адрес загрузки, и если загрузчик не смог загрузить библиотеку по этому адресу, то разделение страниц между процессами идёт лесом. В x64 с этим проще, поскольку там наконец появилась rip-relative адресация. Я за Windows-схему.
    Но вас же разговорить - не самая тривиальная задача. Каждый почему-то боится высказать идею, у которой есть риск оказаться неправильной
    Неправильная точка зрения. Все, кто работает, не любят высказывать идеи, которые они не готовы реализовывать, а все, кто не работает, кричат "дайте то-то" или "сделайте то-то" в соответствующих темах, не доходя до ядра.
    Ушёл к умным, знающим и культурным людям.
  • diamond wrote:Одну и ту же физическую страницу можно отобразить на совершенно разные логические адреса
    Да это как раз понятно. Я имел в виду виндячую систему: другой адрес => изменения от релокации => срабатывает (а куда деваться-то) COPY_ON_WRITE - получается именно то самое "идет лесом".
    diamond wrote:Я за Windows-схему.
    Ну и я - тоже. Хотя бы потому, что с линухом никогда не работал :lol:
    Но мои "фантазии" не подкреплены Вашим опытом, и Вашими знаниями кодов ядра, коллеги.
    Ну, например, нафантазируйте схему, типа: встретили либу первый раз - аллоцировали ее туда-то (а сегмент данных - туда-то), встретили второй раз - поступили так-то....
    На словах, в виде идей. Не, ну желательно продуманных :)
    А кодинг, предположим - за мной. Не сразу, естественно - сначало мне придется "разобраться" с менеджером памяти, и всем связанным с этим мероприятием.
    Но, состояние с ясной целью - это же совсем иное состояние, отличающееся от сегодняшнего.
    diamond wrote:Неправильная точка зрения.
    Это еще не точка зрения. Это сложившееся ПОКА ощущение :)
    Ну вот Вам и тест на разговорчивость (таких есть у меня):
    1) Показалось мне, что встречавшиеся фразы про "тяжесть переключения задач в текущей реализации" (может быть не очень точно - пишу по памяти) связаны с ожиданием, которое осуществляется вызовом do_change_task В ЦИКЛЕ.
    2) Смотрю в коды. Ну ничего вроде венного - и больше порой пишут. Остановился на том, что "тяжесть" заключается в изменении CR3
    3) Прав я или нет - фиг его знает, не имею я опыта программирования в 0-м кольце.
    4) Исходя из своих предположений (возможно, не очень точных) сотворил иную технику ожидания - event.inc::Wait_events[_ex]
    5) Коллеги, но никто ведь не сказал ни - "ай как хорошо", ни - "а на фига козе баян" :D
    6) Можно конкретизировать вопрос до предела: переделать 5-ю ф-ю с использованием Wait_events_ex (ф-я ожидания возвращает тождественный нуль - все становится сверх-тривиальным) - ЭТО ПРАВИЛЬНО, ИЛИ НЕТ :?: :)

    Это как бы я хотел обратить внимание на то, что каким-то путем я таки двинулся, а коллеги молча смотрят (имея значительно больший опыт на этих "горных трассах") :D
  • diamond не путаю, просто одновременно всё в голове крутится )), на самом деле тут три идеи, MMF, разделяемая память и подкачка (или виртуальной памятью это правильнее назвать?). Про kpack за неиспользованием забыл.
    и если загрузчик не смог загрузить библиотеку по этому адресу, то разделение страниц между процессами идёт лесом
    А как работает либа в "неродном" адресном пространстве? есть например у нас две либы с одним предпочтительным адресом?
  • Тема viewtopic.php?f=2&t=32 , дубль 2?
    А как работает либа в "неродном" адресном пространстве? есть например у нас две либы с одним предпочтительным адресом?
    Есть таблица перемещаемых элементов (кстати, в используемом сейчас COFF она тоже есть, и сейчас в Колибри всё происходит так же за вычетом того, что нет предпочтительного адреса загрузки), и при загрузке не по родному адресу происходит коррекция всех адресов. Это несколько замедляет загрузку (по сравнению с концепцией Linux) за счёт отсутствия замедления при работе (по сравнению с той же концепцией).
    Ушёл к умным, знающим и культурным людям.
  • Как человек, обладающий только теоретическими знаниями по ядростроению, а не практическими навыками хочу заключить следующее (возможно я и ошибаюсь):

    Описанная проблема мне напоминает пасьянс - надо знать откуда брать карты, куда и перекладывать и как это делать. "Откуда" определяется форматом исполняемого файла/библиотеки, "куда" - архитектурой ЭВМ, "как" - алгоритмом соответствующей процедуры ядра (загрузчиком).

    Мои соображения: определиться с форматом файлов (я не предлагаю кардинально переходить на ELF или PE, хотя ИМХО было бы не плохо), насчёт вопросов реализации - это дело ядерщиков... Немногие сумеют решить эту непростую задачу... Большой "плюс" - то, что проблема не горит... (система работает стабильно, памяти вроде хватает...)
  • Who is online

    Users browsing this forum: No registered users and 5 guests