Need For Speed Hot Pursuit 2 жрёт over 20 гигов виртуальной памяти.

А что за видеокарта?

Интел X3100 (33-й чипсет). Раньше, когда Вайн был версий 0.9.5х, и иксы не глючили, оно летало.

На память пофиг, по большому счёту. Тормозит отрисовка - это мешает.

CS-1.6 и Source вылетают при попытке использовать что-то, отличное от софтварного рендера. И Вайн на GLX ругается. Кривая сборка?

может драйвер надо переустановить?

> Wine

Дальше можно не читать.

Что не так?

Скоро посмотрю под Джентой - узнаем.

>Интел X3100

лол, у мя на буке даж кс1.6 с лагами идёт на любом драйвере, а вы хотите в НФС поигарть :D

Раньше, когда трава была мягче, а ЛФС занимал меньше времени, оно работало почти Идеально.

>70 fps в контре мне хватало. А тут что-то сломано, хочу узнать что и как исправить.

>Дальше можно не читать.

Толсто. Судя по winehq, должно работать нормально. Но вообще, это интел, да.

на ati бегало отлично, видимо проблема в intel

Всем спасибо, буду ковырять видео.

откуда у тебя 20 гигов? Или ты специально своп наращивал, пока нфс не запустился? o_0

Оно за собой потащило 6-7 процессов, жрущих по 3-4 гига виртуальной памяти.

Сам процесс жрёт меньше Амарока %)

Памяти 2 гига, своп - 1.5.

Размер виртуальной памяти = физ. память + своп. Максимум процесс может занять (3.5гб - ядро с остальным софтом). В твоем случае память заняли какие-то динамические библиотеки, которые и были подключены этими процессами. В ps выглядит так, что каждый процесс столько занимает. В общем не пиши всякую чушь.

Что отображается в столбце "VIRT" команды top? Придумай отмазку получше.

И да, максимальный размер виртуальной памяти никоим образом не зависит от суммарного обьёма физической памяти и свопа.

Википедию сам прочитаешь?

//Что за глупая привычка показывать человеку ошибку, не разбираясь в вопросе?..

Извини, не думал, что ты такой нервный. Хотел объяснить...

o: VIRT -- Virtual Image (kb) The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out.

Что подтверждает мои слова.

А теперь расскажи от чего зависит размер виртуальной памяти?

>It includes all code, data and shared libraries plus pages that have been swapped out.

Это всего лишь неполное описание.

Каждому процессу выделяется адресное пространство в размере 4(че-ты-рёх) гигабайтов. А где и как это хранить - забота ядра.

Дальше в википедию/гуголь, ибо тред о другом.

> Каждому процессу выделяется адресное пространство в размере 4(че-ты-рёх) гигабайтов.

С какой стати? И где оно выделяется? В таблицах страниц?

Да, тред не о том, так что больше отвечать не буду.

Не нервничай. Вот скрин (~120KB): http://itrash.ru/idb/de85181d834d80f00d643d06547f25e3/obug5.jpeg

Я тебе в первом же посту написал, почему так. В адресное пространство всех этих процессов подключены одни и теже библиотеки, которые загружены в память есно один раз и есно памяти виртуальной они занимают, как размер библиотек + размер процессов. Top и ps просто не знают, как еще это показать и показывают vsz для каждого процесса вместе с библиотеками, даже если много процессов использует код одной и той же библиотеки.

Если не веришь мне, посмотри сюда:

http://www.opennet.ru/base/sys/pmap_memory.txt.html

Сначала ты скажешь почему 3+3+3+3+3 != 15, т.е. где вышесказанное противоречит заголовку, к которому ты решил придраться.

Потом интересно увидеть цитату одного из моего постов, где я утверждаю обратное чему-то подобному "В адресное пространство всех этих процессов подключены одни и теже библиотеки, которые загружены в память есно один раз и есно памяти виртуальной они занимают, как размер библиотек + размер процессов.".

Ну а под конец - ответа на вопрос почему ты продолжил тему, сказав обратное.

А если ты в состоянии оценить итоги треда, то ты поймёшь что мы просто считали разные вещи, и не будешь загрязнять тред оффтопом.

Кстати, стоящие советы по теме будут?

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

По теме думаю дело в кривом драйвере видюхи. Потому что у меня на нвидии тоже нормально игра идет.

> у мя на буке даж кс1.6 с лагами идёт на любом драйвере, а вы хотите в НФС поигарть :D

драйвер похоже кривой просто. я в свое время, на старом ноуте нормально играл в контру под вайном на 945 интельной железке.

>Интел X3100 (33-й чипсет). Раньше, когда Вайн был версий 0.9.5х, и иксы не глючили, оно летало.

а Кеды какие были?
просто у меня при включенных эффектах фпс в glxgears падал в 6(шесть) раз, правда на nvidia, откатился на awesome

Ты чушь порешь. Разобрался бы для начала что такое виртуальная память.
Сделай malloc на 125 гиг, top тебе покажет, что виртуальная память 
процесса 125 гиг. И какие же нахер данные там будут лежать?

#cat 1.c
#include <stdlib.h>

int main(){
        int * a = malloc(125L * 1024L * 1024L * 1024L);
        getchar();
}

#echo "1" > /proc/sys/vm/overcommit_memory
#./a.out&
#top

top - 17:27:16 up 3 days,  8:27,  4 users,  load average: 0.06, 0.03, 0.00
Tasks: 147 total,   2 running, 145 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.2%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4050588k total,  3869332k used,   181256k free,   734916k buffers
Swap:  4195760k total,     3088k used,  4192672k free,  1426672k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2027 root     20   0  125g  412  328 S    0  0.0   0:00.00 a.out


А на 32х битной системе максимальный размер виртуальной памяти составляет 4 гига, из них на под пространство ядра выделяется либо 1гиг (по-умолчанию в линухе) либо два гига (по умолчанию в венде), при этом, естественно, top больше 3 гиг показать не сможет.

> Top и ps просто не знают, как еще это показать и показывают vsz для каждого процесса вместе с библиотеками, даже если много процессов использует код одной и той же библиотеки.

А как это еще можно показать? Виртуальная память на то она и виртуальная, что для каждого процесса своя.

glxinfo покажи, может у тебя программный рендеринг используется

wyldrodney@desktop:~$ glxinfo | grep -e ":"
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX version: 1.2
GLX extensions:
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) G33 GEM 20090326 2009Q1 RC2
OpenGL version string: 1.4 Mesa 7.4
OpenGL extensions:

Через пару часов попробую другую версию MesaLib, там отпишусь

> #echo "1" > /proc/sys/vm/overcommit_memory

Бугага. Ты сам сказал линуксу, отключить ограничения _имеющейся_ виртуальной памяти и эмулировать бесконечную. В обычных условиях malloc() вернет NULL.

Что такое "_имеющейся_ виртуальной памяти" ? Виртуальная память к имеющейся физической никакого отношения не имеет. Виртуальным адресам не всегда сопоставляются физические. И никто ничего не эмулирует и тем более бесконечную память. В аллакаторе может стоять, а может и не стоять ограничителя по выделению памяти. Ограничитель этот надо сказать тупой. Да он как-то ориентируется на размер свопа и оперативки, но ничто не мешает мне создать 10 процессов и выделить по 8 гиг в каждом даже с ограничителем и что это будет значить, что у меня в системе 80 гиг физической памяти?

Кстати не забываем еще про mmap. Я могу заmmap'ить хоть весь терабайтный винчестер, top покажет, что виртуальной памяти у процесса терабайт.

Угу, согласен. Не прав.