From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2CA5AC433F5 for ; Thu, 18 Nov 2021 14:35:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 14CF4611BF for ; Thu, 18 Nov 2021 14:35:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233743AbhKROib (ORCPT ); Thu, 18 Nov 2021 09:38:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233393AbhKROiB (ORCPT ); Thu, 18 Nov 2021 09:38:01 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D5671C061757; Thu, 18 Nov 2021 06:35:00 -0800 (PST) From: Sebastian Andrzej Siewior DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1637246099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=++fnSqF7SKAvIK4Pg185tBBXPEgD0u7ybbMtaGqP/oQ=; b=loStlT89MAtHaI/zTxAm48gHA9I4WMx6Xe+ok54Fi1OSNDgGLOPOW0exoN2r3lKYuAS8Tx mK2KKKHQHZWsVtzK9GxxcreUS2vlvNYb/wMxGzRYTZoL0cC1tYsdLoEY8JRoHgS4FsoRCx a/Eioymf24/FswioXHk4ivWdWdP4Cf/Q7Yx0NNY/rE+RtltkiCprH0w8MblVJpcsvUx2xr Xejq/orSNm2nBrXMvTG2yaopc9bymQ/EOS0voE6hc0Dl36Dw43MRYgVs4oujBBMQNU0ewu 69JJ5qHzRoh0Stoo2WZs9n8WrB1D9iN6JuBW9aYfyJhFWM0qb1a3tGfX3Da2tA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1637246099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=++fnSqF7SKAvIK4Pg185tBBXPEgD0u7ybbMtaGqP/oQ=; b=ghbUpXniAXTb77umNwBX6q41XWb+43BQDDIglzzWaE9td3kjtJQo1WGofXhnTXw/gXQ0ka 00OjC2nbVsvgeABg== To: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , Andy Lutomirski , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Daniel Bristot de Oliveira Subject: [PATCH 0/8] kernel/fork: Move thread stack free otu of the scheduler path. Date: Thu, 18 Nov 2021 15:34:44 +0100 Message-Id: <20211118143452.136421-1-bigeasy@linutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a follup-up on the patch sched: Delay task stack freeing on RT=20 https://lkml.kernel.org/r/20210928122411.593486363@linutronix.de It addresses the review feedback: - Decouple stack accounting from its free invocation. The accounting happens in do_exit(), the final free call happens later. - Add put_task_stack_sched() to finish_task_switch(). Here the VMAP stack is cached only. If it fails, or in the !VMAP case then the final free happens in delayed_put_task_struct(). This is also an oportunity to cache the stack. >From testing I observe the following: | bash-1715 [006] ..... 124.901510: copy_process: allocC ff= ffc90007e70000 | sh-cmds.sh-1746 [007] ..... 124.907389: copy_process: allocC ff= ffc90007dc4000 | -0 [019] ...1. 124.918126: free_thread_stack: cach= e ffffc90007dc4000 | sh-cmds.sh-1746 [007] ..... 124.918279: copy_process: allocC ff= ffc90007de8000 | -0 [004] ...1. 124.920121: free_thread_stack: dela= y ffffc90007de8001 | -0 [007] ...1. 124.920299: free_thread_stack: cach= e ffffc90007e70000 | -0 [007] ..s1. 124.945433: free_thread_stack: cach= e ffffc90007de8000 TS 124.901510, bash started sh-cmds.sh, obtained stack from cache. TS 124.907389, script invokes its first command, obtained stacak from cache. As you can see bash was running on CPU6 but its child was moved CPU7. This happens a lot, maybe because my test system is too idle. TS 124.918126, the first command is done, stack is ached on CPU19. TS 124.918279, script's second command, stack from cache. TS 124.920121, the command is done. The stack cache on CPU4 is full. TS 124.920299, the script is done, caches stack on CPU7. TS 124.945433, the RCU-callback of last command is now happening. On CPU7, which is where the command was invoked (but not running). Instead of freeing the stack, it was cached since CPU7 had an empty slot. \o/. If I pin the script to CPU5 and run it with multiple commands then it works as expected: | bash-1799 [005] ..... 993.608131: copy_process: allocC ff= ffc90007fa0000 | sh-cmds.sh-1827 [005] ..... 993.608888: copy_process: allocC ff= ffc90007fa8000 | sh-cmds.sh-1827 [005] ..... 993.610734: copy_process: allocV ff= ffc90007ff4000 | sh-cmds.sh-1829 [005] ...1. 993.610757: free_thread_stack: cach= e ffffc90007fa8000 | sh-cmds.sh-1827 [005] ..... 993.612401: copy_process: allocC ff= ffc90007fa8000 | <...>-1830 [005] ...1. 993.612416: free_thread_stack: cach= e ffffc90007ff4000 | sh-cmds.sh-1827 [005] ..... 993.613707: copy_process: allocC ff= ffc90007ff4000 | sh-cmds.sh-1831 [005] ...1. 993.613723: free_thread_stack: cach= e ffffc90007fa8000 | sh-cmds.sh-1827 [005] ..... 993.615024: copy_process: allocC ff= ffc90007fa8000 | <...>-1832 [005] ...1. 993.615040: free_thread_stack: cach= e ffffc90007ff4000 | sh-cmds.sh-1827 [005] ..... 993.616380: copy_process: allocC ff= ffc90007ff4000 | <...>-1833 [005] ...1. 993.616397: free_thread_stack: cach= e ffffc90007fa8000 | bash-1799 [005] ...1. 993.617759: free_thread_stack: cach= e ffffc90007fa0000 | -0 [005] ...1. 993.617871: free_thread_stack: dela= y ffffc90007ff4001 | -0 [005] ..s1. 993.638311: free_thread_stack: free= ffffc90007ff4000 and after a warm up no new stack is allocated during its runtime and a cached stack is used instead. Sebastian