Укажите отработанное время

Отработанное время:
Продуктивное время:
Bug 6940 - Проблема со сбросом кеша при закрытии   Make a simular bug
Summary: Проблема со сбросом кеша при закрытии
Status: CLOSED FIXED
Alias: None
Product: CIFS@Etersoft
Classification: Продукты (Products)
Component: блокировки файлов и доступ (show other bugs)
Version: не указана
Hardware: PC All
: P4 minor
Target Milestone: ---
Deadline: 2011-05-31
Assignee: Pavel Shilovsky
QA Contact: Vitaly Lipatov
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 6765
  Show dependency treegraph
 
In work:
Reported: 2011-02-20 15:58 MSK by Pavel Shilovsky
Modified: 2012-02-27 10:28 MSK (History)
2 users (show)

See Also:
Заявки RT:
Связано с:
Дата напоминания:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Shilovsky 2011-02-20 15:58:29 MSK
Проблема детально описана тут: http://bugs.etersoft.ru/show_bug.cgi?id=6817#c1.

Ещё давно был создан пробный патч:
http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=commitdiff;h=a33d749928c9028e0c956c9b61cb1d9ed22effa1

Надо посмотреть, как сейчас с этим на текущем ядре и разобраться с проблемой.
Comment 1 Pavel Shilovsky 2011-02-22 18:16:17 MSK
Исследовал проблему - гипотеза о том, что writepages не успевает снять блокировку со страницы кеша при закрытии, не подтвердилась. Видимо, это какой-то внутренний VFS процесс. Создал скрипт, воспроизводящий проблему, и поправил патч. Отправил в linux-cifs@ рассылку.
Comment 2 Pavel Shilovsky 2011-02-22 23:33:16 MSK
После дополнительных исследований выяснилось, что причина не в том, что страница заблокированна, а в том, что количество ссылок на страницу превышает требуемое число - страница используется где-то ещё.
Вследствии этого, становится не ясно - можно ли использовать функцию invalidate_inode_pages2. Проблема требует дальшейшего исследования.
Comment 3 Pavel Shilovsky 2011-02-22 23:33:32 MSK
Патч из рассылки отозвал.
Comment 4 Pavel Shilovsky 2011-02-25 12:19:19 MSK
Глубже исследовал проблему. Выяснил, что в ядре есть buddy page allocator, который периодически захватывает страницы памяти (увеличивает количество ссылок на страницу) и, поэтому, invalidate_remote_inode не всегда срабатывает, так как там идёт ещё и проверка на количество ссылок.

Что же касается invalidate_inode_pages2, то там удаляются и такие страницы. Видимо, это сделано специально, так как в комментариях к функции invalidate_complete_page2, которая вызывается для каждой страницы айнода в этом случае, так и написано, что она не оставляет страницы, если даже на них есть ссылки из вызова shrink_page_list (который использует buddy page allocator) или они временно находятся в векторах страниц.

Таким образом, использование invalidate_inode_pages2 оправданно в данном случае.

Далее займусь правкой патча, и его пробросом с апстрим.
Comment 5 Pavel Shilovsky 2011-02-25 22:44:54 MSK
Подготовил и отправил патч в апстрим. Пробросил в ветку для 35 ядра http://git.etersoft.ru/people/piastry/packages/?p=etercifs-sources.git;a=shortlog;h=refs/heads/v2.6.35. Протестировал с помощью RECT, проблема себя не воспроизвелась.
Comment 6 Pavel Shilovsky 2011-02-28 23:16:47 MSK
Патч получил Reviewed-by тэг. Жду принятия в апстрим и закрываю багу.
Comment 7 Pavel Shilovsky 2011-03-02 19:54:38 MSK
Отправил скрипт, воспроизводящий проблему. Вопрос о принятии патча в ядро до выхода 2.6.38 пока открыт.
Comment 8 Pavel Shilovsky 2011-03-02 22:06:46 MSK
Отправил более подробное описание к своему патчу, так как возникли вопросы.
Comment 9 Pavel Shilovsky 2011-03-10 08:50:40 MSK
В linux-fsdevel патч, но так и не получил комментариев. Жду решения от апстрим о дальнейшей судьбе патча.
Comment 10 Pavel Shilovsky 2011-03-16 00:03:47 MSK
Обсудил текущий статус патча с разработчиками. Высказалась идея о том, чтобы не просто выдавать сообщение об ошибке при невозможности обнулить кэш, а возвращать её пользователю. Если дальше возражений не последует, то буду править патч.
Comment 11 Pavel Shilovsky 2011-03-16 02:39:03 MSK
После продолжительного обсуждения решено было всё же не возвращать ошибку, а просто пометить кэш снова невалидным. Отправил патч в рассылку.
Comment 13 Pavel Shilovsky 2011-03-23 11:05:40 MSK
Надо разобраться с логикой возвращаемого значения функции cifs_invalidate_mapping.
Comment 14 Pavel Shilovsky 2011-03-23 12:33:20 MSK
Исследовал данную проблему. Поделил вызовы, использующие cifs_invalidate на две группы:
1) вызовы которой должны реагировать на ошибку -EBUSY и возвращать её: cifs_d_revalidate, cifs_file_aio_read (будущая реализация), cifs_file_strict_mmap.
2) вызовы которой не должны обращать на данную ошибку внимания: cifs_getattrs, cifs_lseek, cifs_fsync.

Написал об этом разработчиками. Жду их комментарии.
Comment 15 Pavel Shilovsky 2011-03-24 16:02:58 MSK
Получил одобрение по поводу своего предложения. Далее займусь реализацией.
Comment 16 Pavel Shilovsky 2011-03-24 17:45:43 MSK
Создал патч, потестировал и отправил:
http://article.gmane.org/gmane.linux.kernel.cifs/2832.
Comment 17 Pavel Shilovsky 2011-03-25 07:56:50 MSK
Получил комментарии, написал свои соображения.
Comment 18 Pavel Shilovsky 2011-03-26 11:19:09 MSK
Согласно результатами обсуждения поправил патч, протестировал и отправил в рассылку.
Comment 19 Pavel Shilovsky 2011-03-28 16:26:04 MSK
Выяснилось, что не стоит обращать внимание на -EBUSY в fsync вызове - далее буду править патч и тестировать заново.
Comment 20 Pavel Shilovsky 2011-03-28 22:21:54 MSK
Поправил, потестировал и отправил в рассылку новую версию патча:
http://article.gmane.org/gmane.linux.kernel.cifs/2874.
Comment 21 Pavel Shilovsky 2011-04-05 10:17:00 MSK
В апстрим пересмотрел своё мнение по поводу данного патча - патч в данном своём виде не имеет смысла. Появилась идея разбить функцию cifs_invalidate_mapping, и вызывать непосредственно invalidate_inode_pages2 и filemap_write_and_wait там, где это нужно.
Comment 22 Pavel Shilovsky 2011-04-07 22:22:49 MSK
Начал работу над патчем:
http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=commitdiff;h=2b416980d89aa0c69a308a85192a06206389b3d2
Далее добавлю функцию launder_page.
Comment 23 Pavel Shilovsky 2011-04-08 12:03:50 MSK
Добавил функцию launder_page и потестировал код. Отправил в рассылку:
http://permalink.gmane.org/gmane.linux.kernel.cifs/2973
http://permalink.gmane.org/gmane.linux.kernel.cifs/2972
Comment 24 Pavel Shilovsky 2011-04-10 11:38:17 MSK
Согласно полученному комментарию, переделал первый патч и отправил.
Comment 25 Pavel Shilovsky 2011-04-12 23:12:36 MSK
Поправил второй патч согласно полученным комментариям и отправил в рассылку.
Comment 26 Pavel Shilovsky 2011-04-22 00:29:04 MSK
Провёл тестирование производительности первого патча с помощью dbench (результаты в норме - производительность не ухудшилась) и продолжил обсуждение, начатое в http://bugs.etersoft.ru/show_bug.cgi?id=5342#c33 по второму патчу. Возник вопрос о необходимости делать flush в getattr - выяснили, что это мало влияет на логику работы (так как данные в слушае отсутствия оплока сразу сбрасываются на сервер и ситуация, когда flush затронет какие-то данные маловероятна). Но так как мы всё равно проходимся по страницам кэша, возможно падение производительности, что и собираюсь выяснить далее.
Comment 27 Pavel Shilovsky 2011-04-22 12:18:24 MSK
Наблюдал не большое падение производительности (около процента). Всё же ввиду маловероятности данной ситуации и отсутствия реальной необходимости сбрасывать каждый раз данные на сервер, который итак уже сбрасываются вне зависимости от нашего решения в getattr, убрал flush. По той же причине убрал и в llseek. Отправил новую версию патча в рассылку:
http://permalink.gmane.org/gmane.linux.kernel.cifs/3113
Comment 28 Pavel Shilovsky 2011-04-23 10:51:19 MSK
В связи с тем, что реализация writepages в cifs будет изменена на асинхронную, встаёт вопрос, чтобы заранее предугадать эту ситуацию в нашем патче. Поэтому, я предложил использовать функцию filemap_fdatawait, которая будет ожидать окончания сброса данных на сервер. Так как это нашло подтверждение, то далее займусь правкой патча.
Comment 29 Pavel Shilovsky 2011-04-23 17:40:19 MSK
Поправил патч, протестировал и отправил в рассылку:
https://patchwork.kernel.org/patch/729101/
Comment 30 Pavel Shilovsky 2011-04-23 22:52:54 MSK
Протестировал последний патч с помощью dbench. Наблюдал одинаковые результаты с наличием вызова filemap_fdatawait в getattr и llseek и без него. В общем, патч увеличивает производительность на ~5%. Написал об этом в рассылку.
Comment 31 Pavel Shilovsky 2011-04-26 16:50:09 MSK
Патч получил Reviewed-by.
Comment 32 Pavel Shilovsky 2011-05-04 08:24:29 MSK
Теперь оба патча приняты в for-next ветку (второй: http://bugs.etersoft.ru/show_bug.cgi?id=6517#c34). Бага решена.