относительно snappy,

Я честно не знаю. Жмём очень удобные для сжатия данные очень быстро раза в два-два с половиной. Зип утрамбовал бы их почти вчетверо. Снаппи "за нами" дожимает на треть или чуть больше.

донкихотiv_an_ruпропущено...
... if the access is dense enough.

"Плохие" паттерны доступа + 4-килобайтные страницы = Большая Попа. Иначе зачем бы вообще придумывали большие страницы.
А с другой стороны, массовое тягание больших страниц туда-сюда = Вообще Мега-Попа, потому что в 64 мега внутреннего кэша диска садятся всего 16 таких 4 меговых страничек, ну и вообще мало кайфа таскать такие объёмы впустую.
А причем тут внутренний кэш диска и TLB?Есть у вас диск с 64 мегами RAM и NCQ на 30 команд. Пока я "сам" пишу кусками от 8 кило (одна моя логическая страница, она же текущий "минимум выравнивания" для O_DIRECT) до 1600 кило (мой самый длинный экстент), я могу надеяться, что памяти хватит даже на все 30 комманд, и диск лишней беготни и лишней записи делать не будет. Но я ж не могу дать хинт "дорогое ядро, запиши мне вот эти 24 килобайта из конца этой huge странички, и ещё 32 килобайта из начала следующей", я прохинтую целые странички, две штуки, общим весом 8 мегов. Всё, приехали. Значит надо юзать 4-х килобайтные странички, тогда хинтоваться всё будет правильно. Но каждые 64 гига ОЗУ это 16 миллионов коротких страниц. Тут возникает феерический вопрос --- а влезет ли активное подмножество TLB не то что в кэш TLB, а вообще в кэш проца?

Проясним ситуац,

Да нету никакой зацикленности. Просто была в коде кучка ifdef-ов, через mmap таскать и лочить-разлочивать-хинтовать или всё делать самим с O_DIRECT. В итоге своя обработка рулит, только и всего. В двух последних версиях у нас от mmap остался ровно один mlock в ровно одном цикле --- в выделении своих дисковых буферов. Если что-то всерьёз изменится --- накатим старый дифф и померяем mmap ещё раз.

донкихотА вы реально тестировали, у вас перестройка очереди команд с NCQ на сколько и когда помогает?Мы сами не тестировали, нам клиент подарил результаты их ин-хаус прогонов. На жёстких дисках NCQ от 0% ровно и до +20% им подарил, в зависимости от моделей, причём размер буфера оказался почему-то "в два раза важнее", чем думали, как будто только половина используется действительно для буферизации, а на второй дивайс в тетрис сам с собой играет. На SSD разброс ещё больше --- от 0% ровно до 4-х раз.

донкихотНо честно говоря так до конца и не понял как NCQ соотносится с TLB, т.к. они друг о друге ничего не знают.Если мы "сами" пишем, то никак и не соотносятся. Если надеемся на ядро, то проблема с большими страницами ровно одна --- как бы попросить ядро записать кусочек меньше 4-х мегов.

донкихотЭто потому, что дисковый кэш нужен для перестроения очереди и сглаживания скачков производительности, т.е. когда его достаточно то больше уже не надо.Значит мы ещё не дошли до этого "больше не надо". Разница между 32Мб и 64Мб на диск оказалась заметной.

Crack.tro,

вы забыли определить, эффективность по каким именно параметрам вы имеете в виду.

Проясним ситуацякобы highload и текстовые форматы данных (как и подобия SQL) - уже признак колхозаЧто юзеры закачивают/запрашивают, то и съедается/отдаётся. Попросите, скажем, карту в WKT --- получите текст ("колхоз"), попросите её же в WKB --- получите бинарный поток ("не колхоз").

Проясним ситуацТак никто бинарные форматы и не просит, вот вы и не делаете, это и так понятно.Да нет, просят. Но --- как бы вам ни хотелось --- не все :)

донкихотА подобие SQL это RDF?Это в любом случае неверно. SQL/RDF = type error :) Точнее было бы сказать SQL/SPARQL = EAV/RDF .