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

сначала данные собираются в кеш а только потом сбрасываются на диск.
Не только. Ты прочитай мою ссылочку. Он хранит также то, что было прочитано (а не только для сбрасывания) - как раз для минимизации обращений к диску.
теперь давай ссылочку по кешу системы, куда складываются работающие программы
Гы... Ну подумай сам... Программа это тот же файл, который попадает в дисковый кэш, перед тем как выполняется. Соответственно, второе обращение к ней же (как к _файлу_ - а это неизбежно _перед_ выполнением) полезет не на диск, а именно в память (системный кэш). Кстати, системный кэш не имеет отношения к дисковому - первый поддерживается системой (и независим от устройства), второй - зависим от устройства и весьма ограничен в объеме (а системный может занимать почти всю свободную память, он динамический). В статье речь именно про системный кэш, хотя называют они его дисковым.
PS: Поверь, я знаю о чём говорю - это моя область уже более чем 20 лет Мне просто лень тут ликбезы устраивать, потому как всё уже миллион раз описано.

Ну, и что? Я тут молчу в сторонке в тряпочку - сам не знаю, но интерестно бы узнать... Так кому тут из вас верить-то? Продолжение дискуссии будет?

Прочитал обоих - вс╦ понимаю... только вот один об одном, другой совсем о другом и оба правы, но по своему...
Давайте начн╦м с реестров (не системный реестер, а памятный), ячеек и обсудим подход ядра к контролю памяти с ассемблерной точки зрения. Про биос упустим, так как интеррупты нам только для запросов нужны. Что мы делаем на ассемблере когда разрабытываем? Ничего другого как работаем с интерруптами и памятными блоками, которыми "двигаем", грубо говоря. Например: я хочу показать картинку на экран, она занимает в адрессе ху оперативки какое то место, я беру этот "объект" и передвигаю в ОЗУ графики - вс╦ грубо говоря без динамических проверок. Так вот как только запускается программа (не важно что, хоть системный кадр какой), что с ней происходит - она адрессируется в реестр памяти и откладывается по ячейкам (так как без этого наш машинный код не работал ну никак) в ОЗУ - пока ещ╦ с "системным" кэшом ничего не произошло. Сейчас наша программа занимает место в памяти - назов╦м его спрайт. Происходит запуск. Системное ядро работает следующим пут╦м, после удачного выполнения и если кэш настроен (хоть в память или в диск), то происходит копирование (или как уже описано "сдвиг" нашего спрайта в выделенное место для системного кэша). Отсюда и пош╦л весь смысл винды и вообще подобной системы - системы копировальщика. Когда я делаю программу, то я сам могу, после выхода из не╦, решать совобождать спрайт из памяти или занимать дальше место. Практически я всегда убиваю это место (зачем систему грузить, ведь даже при новой загрузке будет создан новый спрайт или загружен из кэш системы, а не взят старый - что логично и ХП по другому не может, даже свои процессы она грузит в кэш).
Что сделали в Висте. Просто оставили спрайты на резиденцию и стали их контролировать (например приоритет системных процессов и т.д.) - и этим экономить запрос в кэш. Очень удобно для работы с большими файлами (где нужен эксплорер или его перезагрузка). Можно наблюдать после копирования большого файла, когда хрюша пытается перезагрузить свои же процессы из кэш системы, где вс╦ как бы "полз╦т".
К автору. На такой машинке можно и с Вистой поработать.

Так кому тут из вас верить-то? Продолжение дискуссии будет?
Мне верить, конечно Ты ссылочку мою прочитай для начала, может, этого достаточно будет. Я могу рассказать, если мало будет. А gendy, выдимо, таки покопался в гугле и понял что я не просто словами раскидываюсь

Только всё совсем наоборот. Зачем грузить кэш не зная, включен он или нет и работает моя программа ли вообще.

Потому что так работает системный кэш - вс╦, что читается с диска - сначала попадает в кэш, если только приложение (или ОС) явно не хочет этого. Кэш "включен" всегда - он не может быть "выключен". Ещ╦ раз напомню - речь не про что-то, что в железе и именуется кэшем, речь про область памяти, используемую для кэширования самой системой. Раньше это называлось буферизацией, но теперь слово "буфер" уже не отражает всех процессов.

Кэш ядро может вырубить и врубить и будет тебе прямой запрос на память. Я со стороны программера это говорю, а не с пользовательской.
Мне кажется, что ты подразумеваешь под кэшом всю рабочую область системы, где таже загрузка в ОЗУ (тво╦ копирование в кэш). Но тогда название кэш для такого подхода неуместно, так как всегда сначала загрузка в память -> работоспособно да нет -> кэш. Системное кэширование (откладка). Повторная загрузка - проверка суммы в кэше - > загрузка из кэша если да (если нет прямая загрузка) в память -> выполнение -> повторное кэширование.

Как всё сложно. Я не знаю есть кэш, нету кэша. Только вот обратил внимание, что когда загружаешь программу в первый раз, то это происходит очень долго, но если закрыть, а потом загрузить по-новой, то это происходит почти мгновенно. Не думаю, что данные каждый раз грузятся с диска, скорее всего хранятся в оперативке и пока туда не положили ничего другого, очень объёмного, на которое не хватает оставшейся памяти, лежат там.

Блин. Ну прочитай хотя бы статью, для начала. Могу тебе ещ╦ накидать материала, про внутреннее устройство ОС. А потом поговорим.
System cache - это _логическое_ понятие, а не _физическое_, это (грубо) просто область памяти, которая хранит то, что было (должно быть) на диске или любом другом медленном устройстве. Назови это буфером, если хочешь. Называется это кэшем потому, что используется для ускорения доступа. При╦м это термин, который используется разработчиками систем, а не мной придуманный для этого случая.

Мы можем разговаривать, в статье ничего нового для меня нет.
Что ты называешь систем кэшом я уже понял, не знаю в какой области ты там 20 лет занимаешся, но комп и адрессация как были так и остались. Хоть как ты мне говори, потому что мне не раз приходилось писать системные приложения и адрессовать системный кэш - да да в логическом понятии. Где я мог указывать по умолчанию - кешировать, да нет, что и т.д.. Правильно, что понятие логическое, так как он может быть и на диске и в ОЗУ и управляется ядром системы по приоризации. Но загрузка идёт сначала в память - потому что иначе будет проблема с адрессацией в ядре, а потом копирование в кэш. Отсюда и весь смысл такой системы.
Просто подход или со стороны разработки или юзера. Но зачем засорять буфер, если машинный код не рабочий.

Но загрузка ид╦т сначала в память
Ну а кэш по твоему что - не память? Да, сначала оно попадает в память, в ту область которая и является кэшем. Потому уже попадает дальше - в пользовательский процесс. И если я снова обращаюсь (по чтению) к той же части файла, которая уже сидит в кэше (буфере), на диск система не полезет.
а потом копирование в кэш.
Зачем что-то куда-то копировать, если оно _изначально_ читается в кэш (или буфер - назови как угодно, который и так часть памяти)?
OK, спрошу иначе. Что такое filesystem cache тебе знакомо? Что происходит, когда ты открываешь файл и читаешь его? Что происходит когда ты выполняешь процесс? Что происходит (на всех уровнях), когда ты обращаешься к диску (напрямую или посредством файловой системы)?
Но зачем засорять буфер, если машинный код не рабочий.
Потому что файловой системе вс╦ равно, что ты прочитал и для чего - исполняемый файл или просто файл с данными.

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

Ну раз сам признаешь, что по барабану - то смотри что происходит:
- Ты пытаешься выполнить процесс;
- Содержимое файла процесса попадает в кэш файловой системы;
- Процесс выполняется или нет - не суть, он уже в памяти и останется там на некоторое время;
- Ты снова пытаешься запустить тот же процесс - система к диску не лезет, ибо он в кэше.
Вот и вс╦. Разумеется, фичи типа prefetch и superfetch делают это немного лучше и не особо зависят от свободной памяти, но если е╦ достаточно (т.е. то что попадает в кэш не вытесняется приложениями) то повторый запуск одного и того же процесса уже не включает в себя обращения к диску - соответственно, это происходит очень шустро.

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

Если интересны детали, они тут: http://members.rushmore.com/~jsky/id37.html
Но вс╦ это актуально только для тех, кто постоянно что-то запускает и закрывает, для большинства все эти оптимизации и прочая незаметны.