HPC.ru lite - Все форумы
Форум: Периферия и карты памяти CF, SD, MMC
Тема: файл подкачки для плеера?
Страницы: 1 [2]

[Ответить]
ВадимП [29.05.2006 20:27] :
Точно так же, как и на настольном компьютере. Попробуйте запустить несколько ресурсоёмких приложений одновременно (не обязательно, чтобы они исполнялись, достаточно, чтобы просто висели, занимая ОЗУ), а потом запустите какую-нибудь интерактивную программу и сравните скорость ее работы при включеном разделе подкачки и с выключеным. Думаю, что разницу заметите сразу.
И это нисколько не удивительно: если какие-то приложения НЕ активны, то разницы будут ли страницы памяти этих приложений перемещены на более быстрый или более медленный носитель нет - Вашей программе в любом случае достанется больше ОЗУ.
sshd [29.05.2006 20:50] :
ну зато будет тормозить переключение между ними.

а зачем мне больше?
если программе нужно 2Мб памяти, то пусть ей хоть 10 дадут, быстрее она от этого работать не будет.
ВадимП [29.05.2006 21:08] :
Могли бы уточнить: сколько конкретно памяти в мегабайтах необходимо, скажем,браузеру? Это вообще величина постоянная?
fenec [29.05.2006 21:19] :
вопрос на засыпку?
sshd [29.05.2006 21:57] :
она может и не постоянная, но в среднем не превышает определённых значений. т.е. скажем так: мне хватает памяти на одновременный запуск ICQ, MSN, TCPMP и нескольких окошек PIE.
да и вообще, насколько удобно работать с browser'ом, если он постоянно свопится?
(чисто теоретически, на покете "лишние" бэкграундовые процессы должны прибиваться. другой вопрос, что на практике это не очень-то работает....)
ВадимП [29.05.2006 22:41] :
Конечно, перемещение памяти процесса на внешний носитель замедляет потом переключение на него. Это бесспорно. Но, тем не менее, всё равно это переключение происходит много быстрее, чем повторный запуск.
Примерно можно сравнить следующим образом - восстановление состояния системы после suspend-to-disk происходит гораздо быстрее, чем запуск ОС и всех приложений с нуля.
Последнее сравнение, правда, не полностью применимо в случае КПК - запуск приложений там зачастую осуществляется из внутреннего флеша, а swap располагается на более медленных флеш-картах.
Но, проигрывая в скорости переключения, мы резко выигрываем в скорости работы активного процесса - понятно, что чем больше памяти для буферов сможет отвести тот же браузер, тем быстрее там будет происходить, скажем, перемещение вперед-назад по страницам. И так далее.
Насколько я понял, мой оппонент не пользовался сам лично swap'ом на КПК и рассуждает больше из общих соображений.
У меня было три года, чтобы как следует поработать и оценить субъективные ощущения от использования раздела подкачки.
И могу определенно сказать, что в целом ряде случаев выигрыш оказывается очень ощутимым (не всегда, конечно - если нет дефицита памяти, то не будет и ускорения работы).

Кстати, даже без использования такого файла система может всё равно осуществлять подкачку - неизменяемые страницы могут просто уничтожаться (во всех известных мне случаях, это страницы содержащие только код), а потом заново подчитываться из исполняемого файла.
Darkcat [30.05.2006 03:07] :
... если памяти хватает своп лучше не использовать вообще. Операции перекачки страниц тоже отжирают время и ресурсы, а нормальная система постарается держать побольше свободной оперативки (про запас), так что своп имеет смысл разворачивать только в случае дефецита памяти.

Уничтожение страниц с кодом это не тоже, что подкачка, и реализуется на уровне повыше (механизм овелеев, встроен обычно в программу, а не в операционную систему). Например в одной моей проге был основной модуль на 30-40 кб (всегда в памяти и активен) и блок оверлеев, суммарно 200 кб. На работу этих оверлеев выделялось от 30 до 100 кб. По необходимости они подгружались (силами программы), отработав убивались (память помечалась как свободная). В принципе для нормальной работы хватало и 25%го окна (размер буфера = четверть от суммарного объема оверлеев), на 50% все летало и очень редко перекачивалось по 2 раза (прога имела вагон модулей, далеко не все из них использовались в один сеанс). Так работают сейчас Фотошоп (свой файл подкачки), Ворд (классические оверлеи) и т.п.
sshd [30.05.2006 10:13] :
!!! вот именно.
у меня на покете 64Мб памяти никогда полностью не заполняются.
(при нормальной работе).

это отключаемо (не для обычного юзера).

эээ....... где это "обычно"? во всех современных виндах прога запускается через особый вид memory mapping'а, и страныцы выгружаются (если это хитрым образом не запретить).
ВадимП [30.05.2006 11:08] :
Совершенно верно, sshd прав - когда я говорил о уничтожении страниц с кодом, я, разумееется, имел в виду только возможности предоставляемые операционной системой.
Я полагаю, что ни для кого не секрет, что при запуске процесса исполняемый файл не считывается в обязательном порядке целиком в память. Вместо этого устанавливается отображение дискового пространства занимаемого файлом программы на определенный участок ОЗУ. Поскольку речь в данном случае идет о виртуальной памяти процесса, то совокупность выделенных процессам объемов памяти может многократно превосходить физический объем ОЗУ.
Этот процесс, как справедливо заметил sshd, называется memory mapping.
Когда управление передается на код, расположенный в другом участке того же файла, происходит исключение и процесс временно прерывается.
В процессе обработки исключения ОС подкачивает из файла необходимые страницы памяти и управление возвращается процессу. Таким образом подобная загрузка по запросу (demand-loading) совершенно прозрачна для процесса.
Если для загрузки очередной порции страниц не хватает свободной оперативной памяти возникает необходимость освободить часть ОЗУ.
Это происходит в результате прямо обратного процесса - .memory unmapping.
То есть страницы с атрибутом "только чтение" никогда не перемещаются в swap - они просто уничтожаются. Бессмысленно тратить время на их перемещение в раздел подкачки чтобы в результате получить две абсолютно идентичные копии страниц - в файле и в swap'е.
За более подробной информацией лучше всего обращаться непоследственно к первоисточнику: файлам /usr/src/linux/mm/memory.c и /usr/src/linux/mm/mmap.c
Там же можно видеть, что загрузка по запросу была реализована в подсистеме памяти Linux'а еще 15 лет назад.
sshd [30.05.2006 11:25] :
или, в случае wince:
WINCE500\PRIVATE\WINCEOS\COREOS\NK\KERNEL\pgpool.c
WINCE500\PRIVATE\WINCEOS\COREOS\NK\KERNEL\kwin32.c
WINCE500\PRIVATE\WINCEOS\COREOS\NK\KERNEL\schedule.c
и т.п.
[Ответить]
[< Назад]