[devel] [partially solved] Q: exit_group slowness

[Kirill A. Shutemov]

On Fri, Jun 08, 2012 at 03:46:29PM +0300, Kirill A. Shutemov wrote:
> On Wed, Jun 06, 2012 at 05:31:27AM +0400, Dmitry V. Levin wrote:
> > On Tue, Jun 05, 2012 at 04:10:35PM +0300, Kirill A. Shutemov wrote:
> > > On Tue, Jun 05, 2012 at 04:46:03PM +0400, Dmitry V. Levin wrote:
> > > > On Tue, Jun 05, 2012 at 03:37:19PM +0300, Kirill A. Shutemov wrote:
> > > > > On Tue, Jun 05, 2012 at 01:08:28PM +0400, Dmitry V. Levin wrote:
> > > > > > On Tue, Jun 05, 2012 at 09:06:22AM +0300, Kirill A. Shutemov wrote:
> > > > > > > Похоже вот на это:
> > > > > > > 
> > > > > > > http://lkml.org/lkml/2012/6/3/34
> > > > > > > 
> > > > > > > Ниже по трэду Пол предлагает возможное решение.
> > > > > > 
> > > > > > Спасибо, откат на 3.2.14-std-def-alt1 радикально улучшил картинку:
> > > > > > # env -i strace -r -eprocess /usr/bin/unshare -i /bin/true
> > > > > >      0.000000 execve("/usr/bin/unshare", ["/usr/bin/unshare", "-i", "/bin/true"], [/* 0 vars */]) = 0
> > > > > >      0.001357 arch_prctl(ARCH_SET_FS, 0x7f49add73700) = 0
> > > > > >      0.000457 unshare(CLONE_NEWIPC)     = 0
> > > > > >      0.000200 execve("/bin/true", ["/bin/true"], [/* 0 vars */]) = 0
> > > > > >      0.000350 exit_group(0)             = ?
> > > > > >      0.156461 +++ exited with 0 +++
> > > > > > 
> > > > > > Хотя до идеала еще далеко:
> > > > > > # env -i strace -r /bin/true
> > > > > >      0.000000 execve("/bin/true", ["/bin/true"], [/* 0 vars */]) = 0
> > > > > >      0.000628 exit_group(0)             = ?
> > > > > >      0.000329 +++ exited with 0 +++
> > > > > 
> > > > > exit_group() дорогой только для последнего процесса в namespace, так?
> > > > 
> > > > Да, конечно.
> > > > 
> > > > > Думаю, это цена которую можно заплатить.
> > > > 
> > > > 0.15 секунды это очень долго, то же самое ядро на более простых серверах
> > > > завершает последний процесс в namespace на 1-2 порядка быстрее.  Так что
> > > > вопрос, что не так и как с этим бороться, пока остается.
> > > 
> > > RCU_FAST_NO_HZ не предназначена для больших машин. О чём в явном виде
> > > написано в описании опции. Так что CONFIG_RCU_FAST_NO_HZ=y было ошибкой
> > > для дистрибутивного ядра.
> > > 
> > > Когда моя большая машинка (40 ядер + ht) освободится я попробую
> > > поэксперементировать с этим немного. Есть подозрение, что отмонирование
> > > файловой системы (внутриядерной, в случае CLONE_NEWIPC) плохо
> > > масштабируется на большое количество процессоров даже без RCU_FAST_NO_HZ.
> > 
> > Для справки: на той же машинке (где "rpm --eval %__nprocs" показывает 32) с
> > 3.3.8-std-def-alt1 (с отключенным CONFIG_RCU_FAST_NO_HZ) время завершения
> > "unshare -i /bin/true" уменьшилось примерно в полтора раза по сравнению с
> > 3.2.14-std-def-alt1 (с 0.15 до 0.10 секунды).
> 
> Дима, можешь проверить поможет ли патчик, прежде чем я покажу его
> апстриму:
> 
> From b76600918d021ec9836659dbb991f4d9a92de795 Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov" <kirill.shutemov на linux.intel.com>
> Date: Fri, 8 Jun 2012 15:30:31 +0300
> Subject: [PATCH] fs: push rcu_barrier() from deactivate_locked_super() to
>  filesystems
> 
> There's no reason to call rcu_barrier() on every deactivate_locked_super().
> We only need to make sure that all delayed rcu free inodes are flushed
> before we destroy related cache.
> 
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov на linux.intel.com>

С этим патчем exit_group() у меня отрабатывает за 0.005 - 0.012 секунды.
Приемлимо?

-- 
 Kirill A. Shutemov