Добрый день,

Подскажите, реально ли выделить память только лишь в физической области, т.е. не использовать виртуальную? 
Необходимо использовать только быструю память (работаю с GigE) для кеширования больших данных (4-5GB) перед сбросом их на диск.

Спасибо.

для вянды - писать свой драйвер.
для линукс - модуль ядра.

Добавлено через 14 секунд
да и не надо оно тебе, поверь.

Да, винда x64.

Может уже есть какие-нибудь библиотеки? 
Boost так не может?

Уверен, что писать драйвер мне не надо (не окупится время), а вот чтобы память пользовать - надо. 
А если в настройках операционки убрать фвиртуальную память до минимума?

Это сообщение отредактировал(а) nikkadim - 23.7.2012, 23:19

nikkadim, тебе зачем? почему тебя виртуальная не устраивает? В современных ОС работать с физической памятью могут только ядро и драйверы.

уверен, ты не с той стороны подошел к решению задачи.

Ок.
У меня есть GigE камеры, каждая цепляется к своему PC, поток от них получаю минимум в 600 Mbit/s, мне необходимо из этого потока выделять фреймы и сохранять каждый в TIFF или в RAW где-то. Вот это "где-то" должно быть быстрее чем скорость приходящего потока, чтобы не терять фреймы (терять их я не могу, по условиям задачи). Отсюда возможностей не много, либо к каждому PC цеплять SSD, либо принимать все что валится сначала в выделенный буфер, а по окончанию потока сбрасывать это неспеша на диск.

Это сообщение отредактировал(а) nikkadim - 23.7.2012, 23:49

nikkadim, если у ОС есть достаточно свободной физической памяти, то она ее тебе предоставит через malloc/calloc. Если нет, то сбросит в своп редкоиспользуемый кусок памяти, и отдаст его тебе.

Вот если бы это было действитель но так, наверно я был бы почти щаслив! Спасибо.
Последние Windows релизы (Win7x64) так умеют? Или подскажите плз ключевые слова, чтобы почитать про это.

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


терять ты их можешь тупо из-за того что проц не успевает ;)


ты все сильно преувеличиваешь.
600 Mbit это приблизительно 70 мбайт в сек. не так то уж много. но да, редко какой хард сможет сохранять с такой скоростью без тормозов. RAID в помощь.

Добавлено через 3 минуты и 42 секунды

любые так умеют.


гугл -> malloc

Да нет, проц курит в это время. Граббинг идет через драйвер и SDK производителя камеры, с этим все ок.
А преобразование в формат идет через Libtiff оторый добавляет лишь около сотки байт в заголовок, а далее идет RAW, тоже нагрузки практически нет.
Хороший RAID0 стоит тооже не плохо, как и хороший SDD (возможно и с рейдом) все это приводит к удорожанрию проекта, плюс изначально он планировался мобильным на лэптопах, чтобы можно было приехать быстро развернуться сделать измерения и ехать обрабатывать данные. В случае с рейдом это скорее всего тянет на DesctopPC. Так надо оно, если на борту и так есть достаточно памяти, тем более которая нужна только лишь на минуту или две.

это происходит на отдельном компе? т.е. аппаратная обработка?


неправда.

Нет, это на каждом.

Ок, наврал, около сотни байт еще вконце добавляет. Я не использую сжатие вообще. 
Снимаю с сенсора Bayer-массив как он есть и упаковываю его в TIFF. Но даже если и не упаковывать, разницы в скорости работы с буффером памяти в 500 фреймов с упаковкой в моих условиях нет.
Я мог бы и в RAW писать, если бы libTIFF тормоза давал, а потом уже упаковывать, но дело не в этом, а в том куда байтики польются в момент съемки сначала.

Добавлено через 10 минут и 43 секунды
Я думаю меня вполне для начала устроит факт подсказанный bsa,  нашел еще подтверждение тому в нескольких буржуйских источниках. Я об этом не знал, всегда думал что если физическая память заканчивается, то новые запросы он адресуют уже дальше по адресации в swap.  Правда как и любая дисковая операция это может хорошенько подвесить систему, помню как моя Win95 или 98 просвопивалась на автокадах и прочих студиях.

в линуксе я могу Вам подсказать как сделать, чтобы область памяти была именно в RAM. Это вызов http://www.kernel.org/doc/man-pages/online...n2/mlock.2.html 

В windows не знаю.

Добавлено через 2 минуты и 49 секунд
вот мне тут коллеги подсказывают, что в win это  virtuallock()  http://msdn.microsoft.com/en-us/library/wi...5(v=vs.85).aspx

Интересно, не знал. Спасибо.

в Windows это AWE: http://msdn.microsoft.com/en-us/library/wi...7(v=vs.85).aspx

но для доступа к физической памяти все равно требуется хотя бы небольшое, но виртуальное окно, т.е. тут заморочек еще хватит,
но если нужен простой статический буфер, проблем, думаю, не будет: резервируй диапазон физических страниц, мепируй их на аналогичный диапазон виртуальных страниц и пиши-читай туда что хошь, ни кто его не отберет и не сбросит на диск

Добавлено через 2 минуты и 54 секунды
правда тут потребуются некоторые привилегии,
которые, впрочем, нужны и на virtuallock