woody, нали не си мислиш, че Майкрософт ще пуснат няколко версии на ОС-а - една със swap, когато се инсталира на желязо с хард диск и една без swap, за когато се инсталира на желязо с флаш. Т.е. те пускат една версия, която винаги има swap и това, че той може да се мести в рам-а, колкото и безумно да звучи само помага, когато работиш с флаш памети. Ако вземат да напускат различни версии със и без това и онова накрая ще настанат едни пълни бози. РС архитектурата е пълна с такива примери, когато се прави нещо безумно, само за да се осигури съвместимост назад. Верно е, че това много ебава нещата, а ама пък ако няма съвместимости и всеки път се почва от нула тогава пък ще е пълна каша с приложенията. Така че са необходими някои компромиси .

дааам, накарахте ме да ровя в мезозоя нейде...

М$ в началото (1980) са имали техен хардуер. 16К разширителна платка за ... apple ][



по същество това са банкови памети, предимството на което е неограничения размер на паметта. имах даже по едно време 128К платка (за епъла), защото трябваще да се тиражират стотици дискети и с тая платка можеше цялата дискета да се зареди в паметта и после само запис.

в РС тази концепция намира приложение в EMS паметите

в обикновено РС с 8088 можеше да се добави 4М памет. е, на страници, но можеше...

в 95/98 процесора дефакто работеше във v86, така че XMS май правеше подобни неща.

та предполагам, че пре-вин8 реализацията на swap гони някаква съвместимост с тази концепция.

Дедо, с теа снимки изби рибата на сухо ...

хе-хе, шегувате се вие

woody е абсолютно прав. Swap в ram е безсмислица. Микрософт си имат термин - memory pressure, демек нищо не се свапва докато има налична памет, а като почне да се вдига "налягането" обикновено заявките са в пъти повече от размера на цялата памет. Няма начин като ти трябват 200% да се напъхаш в 20...
Съвместимостта тук няма никакво значение. Още повече, че от край време размерът на свапа може да се конфигурира, т.е. 0 байта не е проблем и не е нужно да има свап само заради идеята.

Чета и не вярвам на очите си.
Едно, че наистина размерът на swap се задава, и нищо не му пречи да е нула. Никоя програма не работи със swap директно нито има концепция за него, това е просто страничен ефект и напълно прозрачно, извън времето за прехвърляне.
Второ, ето какво би се получило при swap в RAM:
1) свободната памет пада под някаква граница, и ОС-ът решава да swap-ва скоро неизползвана RAM памет
2) копира тази RAM към .... другаде в RAM-а
3) освобождава първата RAM от таблиците на принадлежащия процес (маркирайки ги като неприсъстващи)
и при връщането:
4) намира и заделя свободна RAM
5) копира от swap RAM-а към новозаделената RAM
6) маркира в таблиците на принадлежащия процес че отново са достъпни

И това всичкото очевидно може да се замени с ... просто неправене на нищо, като тогава освен доста спестено време дори ще има повече свободна RAM поради липса на особено интересните точки 2 и 5. Да не би дизайнерът на swap в RAM-а да се е казвал Rube Goldberg?

Да, обикновено по embedded swap не се пуска, и не е специално обвързано с M$.


Още ли не осъзнаваш че тази RAM за swap ако я оставиш да се ползва нормално ще е много по-полезна?

Напротив, осъзнавам го ама не ме нервира толкова, колкото теб . Отделно още не съм го виждал тоя Уин 8 та идея си нямам какво са направили. Тони каза нещо тук, после изчезна и всички станаха на кълбета заради тоя swap файл .

ПП. Сега погледнах в 7-цата и ХР-то - в тях също можеш да го изключиш тоя swap файл, та не виждам къде е проблема на цялото това нещо .

И аз имам спомен, че съм виждал изключване на swap файла някъде по xp-то.
Което не знам значи ли, че престава да им трябва де.

Смисълът на това, което woody ти казва е не толкова, че тоя RAM би бил "по-полезен"
а просто, че няма какво да се спечели от цялата работа, може само да се загуби
(добавяне на overhead за swap, поддържане на две копия в RAM докато се swap-и
и т.н. и т.н.).

Би могло да има смисъл ако процесорът е 16 битов, т.е. адресното му пространство е по-малко
от наличната памет. Някакви такива мазала правеха на времето с EMS или кво там беше на
286 и надолу (то и аз по бабички и т.н. правех банки RAM в рамките на 64-те K на 6809,
с кеша за флопитата който бях набутал там машината летеше в сравнение с оригиналните
моторолски машини на които вървеше MDOS - и в това съм преди MS във времето, те разчитаха
на диска да си кеши данните от 90-те насам, преди това нищо нямаха, сега май пак
чакат на диска....).

Айде отплеснах се от работата в минали неща пак. Добре де, ето още едно .
Оригинална TGI машинация в рамките на DPS-а от средата на 90-те (още се поддържа).

Тогава процесорът на който вървеше DPS-ът нямаше MMU (68340) и за swap не можеше
да се мисли в познатия смисъл. Добре ама единият мегабайт (което за 20 MHz процесор
е повече от достатъчно RAM ако диск I/O-то е направено като света и кодът не е
раздут 100+ пъти) взе да не стига с многото прозорци, нали системата трябва да ги
крие някъде като не се виждат и т.н. (не е като в windows да го затрие вместо да го крие
и после приложението да трябва пак да го генерира, мисля, че там е така).
И въведох нещо което би могло да се опише като "cooperative memory swap".
Тасковете можеха (могат го и сега де) да декларират част от паметта, която са получили
(от системата по заявка) като "memory_ block" и оттам нататък преди да пипат в тоя
блок трябва да кажат на системата, че ще го ползват а тя им го гарантира в RAM
(не непременно на същото място). Като не им трябва си казват и системата като получи
заявка за памет от някого ако няма достатъчно почва свободните в момента блокове
да ги изхвърля на диска.
Работи прекрасно - на много ниска цена за програмиране, че и MMU не трябва.
Не съм го виждал другаде като подход (но и далеч не съм виждал всички системи, това
е работа за писачите на монографии ).

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

Е то swap е основна функция, добре е, че я имат. Не е наследство, преди NT нямаха
такива работи (разните подигравки с техниката от рода на 3.11, 95, 98 само това
щеше да им е кусур, те и без него не работеха без непрекъснати забивания).

Просто да swap-иш RAM <> RAMdisk е глупости на търкалета ако паметта не ти
препълва адресното пространство и имаш MMU. И на тях няма какво да им даде,
в никакъв контекст.

98 със сигурност има swap, има и възможност да се изключи. За 95 не знам.

Понякога има смисъл и swap в RAM. Ако паметта не е "активно ползвана" и може да се компресира, тогава има далавера. Ако не може - нЕма далавера.

Още едно трудно за вярване нещо дето ще се окаже истина .
Какъв swap, тя файловата им система едвам се крепеше. Но може и да са го намазали
някак, знам ли. Не вярвам някога да е работило по използваем начин това нещо,
ако е било swap (а не нещо друго на което са казвали така). Никога не съм имал
тук wintel PC от преди 2005-а та наблюденията ми са сравнително бегли (но повече от достатъчни
за да видя каква размазаност бяха).

Ако няма MMU да, това би бил вариант (по подобие на описания от мене по-горе "cooperative memory swap").

Но с MMU е пълна безсмислица и за тая цел, нали това прави page translation хардуерът в MMU-то.

Тая сутрин си викам - бе не може да направят нещо, което е безсмислено ако няма някаква причина. Поразрових се малко и се оказах прав . Имало една камара приложения (къде кофти написани, къде заради нещо друго), които при тръгването си проверяват размера на swap файла и ако е под определен размер дават грешка и не се стартират. Та в тоя случай ако някой има достатъчно рам на компа си е супер нормално да премести swap файла в рам-а, защото така хем програмите му ще работят, хем ще работят по-бързо. На който му се чете повече, ето тук една тема в един форум, която разисква проблема:
http://www.overclock.net/t/1193401/why- ... a-ram-disk
Така че недейте отхвърля веднага всички луди идеи, защото понякога явно има причина някои неща да бъдат направени по начина, по който са направени пък бил той и напълно откачен .