From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 Date: Fri, 8 Jun 2012 18:31:58 +0300 From: "Kirill A. Shutemov" To: ALT Devel discussion list Message-ID: <20120608153158.GA6568@shutemov.name> References: <20120604211117.GA10184@altlinux.org> <20120604223046.GA10007@shutemov.name> <20120605002047.GA11877@altlinux.org> <20120605060622.GA11312@shutemov.name> <20120605090827.GB16122@altlinux.org> <20120605123719.GA12996@shutemov.name> <20120605124603.GA19483@altlinux.org> <20120605131035.GA13142@shutemov.name> <20120606013127.GA29780@altlinux.org> <20120608124629.GA5947@shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120608124629.GA5947@shutemov.name> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [devel] [partially solved] Q: exit_group slowness X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 15:32:02 -0000 Archived-At: List-Archive: List-Post: 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" > 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 С этим патчем exit_group() у меня отрабатывает за 0.005 - 0.012 секунды. Приемлимо? -- Kirill A. Shutemov