Количество cached не влияет на потребление оперативной памяти. Система отдает под него всю свободную память (но есть небольшой "принудительный" резерв всегда), и при необходимости сразу возвращает приложениям.
Однако с какого-то момента (вроде с Windоws XP Serviсe Pack 2) была изменена логика работы с виртуальной памятью и кэшем: система заблаговременно свопит все что только можно в файл подкачки (и код и данные), а в оперативке хранит дубликаты. Как только она считает, что кэша слишком мало - она объявляет место в оперативке, занятое дубликатами, свободным - и отдает его под кэш. Выглядит это, как внезапные тормоза всех приложений - после копирования большого файла. Не встречал инфы, что сейчас что-то поменялось.
В наше время для нормальной работы ОС файл подкачки нужен, но вот с его размером - это вопрос. На 8 Гб лучше оставить все на авто. Если памяти реально много - сделать своп небольшой и ограничить "сверху".
Маленький файл подкачки - размещать на диске, который наименее загружен и самый быстрый (если один HDD диск и 2 раздела - то на первом разделе, т.к. начало диска "быстрее").
В современном ПК, с SSD и HDD одновременно, если виртуальной памяти иногда нужно дофига (т.е. сотни гигабайт - например для обработки карты местности на большой территории в высоком разрешении), то задаем жестко своп на SSD в размере оперативки, и задаем плавающий своп на HDD размером от 800 Мб без верхнего порога. Тогда обычно будет свопить на быстром SSD, а при перегрузе - сливать на медленный HDD.
На HDD своп желательно создавать на дефрагментированном разделе и устанавливать большой минимальный размер - снижает фрагментацию и повышает скорость его работы.
