MySQL работает на Solaris-10 от 60% до 90% быстрее чем на RHAS4

Кукушкин! Уйди-ты со своей культурологией. Тут реально пацаны ядерную войну затеяли ;)

А вот и ссылка http://lwn.net/Articles/176635/

>>ага, хранение полного количества открытых файлов в глобальных per-cpu переменных и проверка при открытии, очень актуально в свете дискуссии про освобождение структуры file, RCU и т.п.

>When a file is closed, the task of freeing the structure is queued in RCU.

>Это цитата с так любимой тобой lwn.

:) а вы хоть видели, что там в rcu происходит? Правильно, там в функции две строчки,вторая из которых kfree(). Ок, формально освобождение структуры происходит в RCU callback, но этому освобождению предшествует немало шагов, которые в RCU контексте не могут быть выполнены. И именно там кроется ошибка. Основная идея принятого патча в том, чтобы проверять общее количество используемых в системе файловых дескрипторов.

Иногда полезно немного думать перед тем как цитировать незнакомых людей.

>>Ага, а теперь давайте вспоминать, о чем вы говорили сначала - правильно о "фрагментации lowmem" (какой термин!), а теперь будем думать, как работа RCU может повлиять на эту самую "фрагментацию lowmem"...

>Тебе же ссылку дали. Йоптыть! Читать не умеешь? Перевести тебе может бедолага?

>But, if the generation of RCU callbacks continues at a high rate, the length of the callback queue can only grow. Every entry in the queue represents memory which could be returned to the system, but which has not yet been made available. So, as the queue grows, memory gets fragmented and the system heads towards the dreaded out-of-memory state.

>Щеки иногда полезно СДУВАТЬ, а нето лопнешь и всех забрызгаешь своим дерьмом...

>Гы! Ты незнаешь что такое lowmem? Теперь о том, что ТЫ говорил сначала:

>1) Говорить о жопе, обнаруженной David Miller и приводящей к полному ступору системы иззи ОШИБКИ в обслуживании очереди RCU как о нормальном поведении

Нет, определенно анонимусы не развиваются. В обработчике RCU нет ошибки, так же как ее нет в коде VFS. Она есть в так называемом file accounting, и была исправлена патчем, о котором я писал выше. То, что там не вызывается больше call_rcu(), не является основным. Подумайте хоть немного, прежде чем говорить глупости.

>>В тестовом перегрузе система заявила, что она перегружена, какие вопросы?

>- ВЕРХ БЕЗГРАМОТНОСТИ. ЗДУЙ ЩЕКИ.

>2) Говорить о userspace и приплетать Lea аллокатор в контексте разговора о исчерпании lowmem - это ли не показатель безграмотности? Ты даже незнаешь что такое low memory - т.е. ты не имеешь представления о модели памяти в лайнаксе. ЗДУЙ ЩЕКИ НЕЗНАЙКА!

:) мой юный друк, у вас истерика.

Я не собираюсь повторять комментарии вашего бреда о фрагментации. Замечу только две вещи: 1. когда цитируете кого-то, нужно понимать, что автор имел в виду, а не переводить его фразу и сидеть с умным видом. 2. ошибки в Linux есть, есть немало серьезных, но _вы_ их описываете _абсолютно_ неверно. Если почитаете предыдущие сообщения, то возможно, хотя я сомневаюсь, что вы будете читать, поймете, где вы были неправы, и что я вам пытался сказать.

>>В ядре slab алокатор один и тот же, что в Linux (2.6?), что в solaris (кстати, в Linux он портирован из sunos).

>В ядре slab аллокатор был еще тогда, когда код соляры небыл открыт. И уже переделывался несколько раз из за проблем с фрагментацией. Хотя это непринцыпиально.

В Linux используется модифицированный аллокатор из SunOS 5.4, полное название "Object-Caching Kernel Memory Allocator".

>Говорить об ошибке в планировщике как о фиче

>>Мой юный друк, вы можете настрить это поведение. По умолчанию позволяло, теперь нет

>Более тупого и в КОРНЕ НЕВЕРНОГО замечания трудно было придумать! Конечно все можно "настроить" например исправив ошибку, что и было зделано "тупым" торвальдсом, который непослушался крутого rtc.

/proc/sys/sched (starvation_limit, max_sleep_avg, interactive_delta, prio_bonus_ratio) в помощь. Этот патч был принят, т.к. это правильное решение проблемы, но это не означает, что другого (как workaround) не существует.

>Да, забыл ответить на этот ОПУС. Ты ЩЕКАСТЫЙ что не чиаешь ссылок, 
которые сам же клянчил? Нехорошо ... Я же тебе дал ссылку на фикс - лазил на gmane искал а ты ?


-/* slab constructors and destructors are called from arbitrary
- * context and must be fully threaded - use a local spinlock
- * to protect files_stat.nr_files
+static inline void file_free(struct file *f)
+{
+percpu_counter_dec(&nr_files);
+call_rcu(&f->f_u.fu_rcuhead, file_free_rcu);
+}


Эта муйня ставит в RCU очередь callback, который освободит  struct 
file.


+static inline void file_free_rcu(struct rcu_head *head)
+{
+struct file *f =  container_of(head, struct file, f_u.fu_rcuhead);
+kmem_cache_free(filp_cachep, f);
+}

>А эта - и есть та самая, которая освобождает.
>Все - больше спорить с тобой никакого фану нет. Обтекай.


Я же несколько раз написал, что основная проблема в file accounting, и ее (временное) решение в этом патче в виде хранения полного количества используемых дескрипторов. 

:)) То, что вы показываете, глупый анонимус, всего лишь перемещение функции из одного места в файле в другое, RCU здесь не при чем.

Основная идея в том, что манипуляции с nr_files изменились.


Так что вы показали себя не с лучшей стороны, хотя я предполагал, что поверхностное изучение патча с вашей стороны приведет к чему-то подобному.

diff -puN fs/dcache.c~fix-file-counting fs/dcache.c
--- linux-2.6.16-rc3-rcu/fs/dcache.c~fix-file-counting	2006-03-05 11:48:53.000000000 +0530
+++ linux-2.6.16-rc3-rcu-dipankar/fs/dcache.c	2006-03-05 11:48:53.000000000 +0530
@@ -1736,7 +1736,7 @@ void __init vfs_caches_init(unsigned lon
 			SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
 
 	filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
-			SLAB_HWCACHE_ALIGN|SLAB_PANIC, filp_ctor, filp_dtor);
+			SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
 
 	dcache_init(mempages);
 	inode_init(mempages);

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

Вот оно, ваше изменение в коде RCU.
Вы просто смешны.


+static inline void file_free(struct file *f)
+{
+percpu_counter_dec(&nr_files);
+call_rcu(&f->f_u.fu_rcuhead, file_free_rcu);
+}

+static inline void file_free_rcu(struct rcu_head *head)
+{
+struct file *f =  container_of(head, struct file, f_u.fu_rcuhead);
+kmem_cache_free(filp_cachep, f);
+}

-static inline void file_free_rcu(struct rcu_head *head)
 {
-	struct file *f =  container_of(head, struct file, f_u.fu_rcuhead);
-	kmem_cache_free(filp_cachep, f);
 }
-
-static inline void file_free(struct file *f)
 {
-	call_rcu(&f->f_u.fu_rcuhead, file_free_rcu);
 }

> Гы! Спасибо. Прасветили аднака. Только мима кассы! Фрагментация происходит(ла)
> из за ошибок в реализации RCU очереди для освобождения file сруктур. Просветлитесь.
>
> ....
>
> иззи ОШИБКИ в обслуживании очереди RCU как о нормальном поведении

не было там ошибки, точка.

1-я проблема в том, что rcu_do_batch() недостаточно агрессивно
"сливает" ->donelist, те очередь callbacks inflight может "слишком"
расти. это не ошибка, хотя поведение, конечно не оптимально, и эта
проблема еще до конца (по моему мнению) не решена, хотя на настоящий
момент большинство неприятностей устранено.

2-я проблема (основная в этом контексте) в том, что --nr_files происходило
в деструкторе slab object, filp_dtor(). те, значительно позже, чем
нужно. это никоим образом не связано ни с фрагментацией, ни с low-mem.
деструктор вызывается тогда, когда slab отдает память системе, что
может случиться значительно позже kmem_cache_free (или вообще никогда).
таким образом, nr_files учитывал в том числе и количество 'struct file'
в slab cache готовых к немедленному использованию. строго говоря, это
тоже не bug сам по себе, однако все вместе и привело к таким неприятным
последствиям.

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

>Ну так скажи ему об этом лично. Обсирать людей за глаза - себя не уважать.

научись быдло правильно слово линукс произносить, а потом только пытайся тявкать