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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5FFECC77B7C for ; Mon, 22 May 2023 03:09:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C49786B0074; Sun, 21 May 2023 23:09:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFA3E6B0075; Sun, 21 May 2023 23:09:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC13F900002; Sun, 21 May 2023 23:09:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 989ED6B0074 for ; Sun, 21 May 2023 23:09:08 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 62D34803A3 for ; Mon, 22 May 2023 03:09:08 +0000 (UTC) X-FDA: 80816409576.02.179F062 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf03.hostedemail.com (Postfix) with ESMTP id E62602000C for ; Mon, 22 May 2023 03:09:04 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=amVE8uj2; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684724946; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=K9MuGJsi5JjLfoRa/mOczbDbsd2ONxYBrKvWRFN07F8=; b=gTshnogO7TqR5VwuwPEKXVcQRFiOthtIEQ/IUET+R0PvB9xHJ1jK0oQWMiyiw9LeSw9Jly ETrLtEFkR2sansCA9HU8+08+ZsAYKxSpuXRjnFtZu9rWynmXt/MM0moShPW+auqN93IpZc NT+h/e0LSy0u/M69CJ6Q0D1qFJsaLCM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684724946; a=rsa-sha256; cv=none; b=O9FqewJn+QnrCY+bP4dySMgmFbHyXaOovmY6eQQlRob4amTif1XApu4XL4EgPFhhTBrDm0 tc0w/NdfW9rcseQJ7gLhx4cn/dea0rPD4kwIkkns1TTN7+UrFy9Fs7eTIQxAFyv+m2QD7x iT2ChfROHGtltu7JoI3yuJYVjNJwK7s= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=amVE8uj2; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684724945; x=1716260945; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=cOG0KYJnKpmi4cHDPDq6VEOZtKKOtmEAWsRIPrEW+cA=; b=amVE8uj261oTNQRHXpNg/2y8GbtozhS/MMAVi9X1LateZnbkrYhWlo+a xFnFmf72qDRR0aH0JNFQp1J8ogY0Opr3MK8+VKDkei8OK8RSjadjqHJv0 kOBiide4/RKGqs1VqQydqoChIbDOq1jbCydf2QradkY21D+ILCeTOlpGv bdC4mPoaOWLtBVFsxUGU4M2MfG9SVpSyxwdb+5woaIZgH86u8B2mtY4sL DktNro1VoEEf3h7+rjZ5OmRhi3atN6x71iybsjGCP0BQQh1PGytPOsk0+ tTJo3Ys+9oh1BNz1mvQhNVps3cmx+X+3Hsrr5txH8b5ddvB/wUQFY14g9 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10717"; a="337402810" X-IronPort-AV: E=Sophos;i="6.00,183,1681196400"; d="scan'208";a="337402810" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2023 20:08:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10717"; a="697491000" X-IronPort-AV: E=Sophos;i="6.00,183,1681196400"; d="scan'208";a="697491000" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2023 20:08:54 -0700 From: "Huang, Ying" To: Tetsuo Handa Cc: syzbot , , Mel Gorman , Vlastimil Babka , Andrew Morton , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Andrey Ryabinin , kasan-dev , linux-mm , Johannes Weiner , Michal Hocko Subject: Re: [PATCH] lib/stackdepot: stackdepot: don't use __GFP_KSWAPD_RECLAIM from __stack_depot_save() if atomic context References: <000000000000cef3a005fc1bcc80@google.com> <48a6a627-183d-6331-0d8d-ae4b1d4b0101@I-love.SAKURA.ne.jp> <9c44eba9-5979-ee78-c9c8-626edc00f975@I-love.SAKURA.ne.jp> <87edn92jvz.fsf@yhuang6-desk2.ccr.corp.intel.com> <0471c62b-7047-050a-14f5-f47dfaffaba7@I-love.SAKURA.ne.jp> Date: Mon, 22 May 2023 11:07:51 +0800 In-Reply-To: <0471c62b-7047-050a-14f5-f47dfaffaba7@I-love.SAKURA.ne.jp> (Tetsuo Handa's message of "Mon, 22 May 2023 11:47:25 +0900") Message-ID: <87a5xx2hdk.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: E62602000C X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: kjb88gpyuh64s9gh1do6zpegn6117hdp X-HE-Tag: 1684724944-934346 X-HE-Meta: U2FsdGVkX185/Qr3y0f8hwxmDxiLF+ftmAEoUi6137hcb+DK3vS9jnmR9ryw4yulCW0QUNpVpuFW8YxbJbJ4iGoKgBU2e5ZqQ5ChLNXt26wgbvJrznSYfrc4/9rvk1+sRZqIETtNT2eVqOaf/IeUmXxC2AhKekKztTse+8Jrjw7ngXzsEocOqklrUIpZnf9Nl4McjMo5LGsThJeRzWkExA7hOJ49MM26tLLRxTj/Qmdmg7YwR1T9d+rIWMQA9w4OxotcJ2F5XIrr01ZpDIPdc1/iHfzdiKtl348f+68dmQQBzLfCTJOtH+DJHrq105flpcTS/UJykj2/w1CG9zJ101Wtn/hT8D9cRi1tX7lQSjNGM2JkPG/vfB4I11wdVHy6DEKZPBuRI00sN+iKTnFBfkLq1spTkx3gsBfHKUBT6isNs7kakf0ynWh3BAsIEELvt8pw9+SDf7JEQLlaFBMR7XAz/qEhryW3jwqDGVyZ5aPta3yuy1Y6duzUlHK96WxMTrtd2/cZyemgjPfPK1+/X6YporQ2eUEeIi3ROkeO4MfDL/+6bad/vHIYeLeGeHm2P6LecVxOLh5vBBynmYkGa+e/cL3AWPL7bQ26OTlVOx2PrCFzoA+MHBczFAtfiYNKF8n6qLh+dzDq7kEAoOiII/U9TrL2hvhWBHQN1NuBqOdfx9Y4xRGsEH8dduCNkoCOeN6BD8TJF4hSO7QmXtXnQ++f9SERqV1czfYR5ic0nzrozHVdOO2+c7q7olKJS8Deckzp3D7BtU98+6KE6bDR/LyRs2wb8K3TovrOIBQA/f7RrydXoJvZFeLzFtyPJnGe4UFR7tZkw6QoHTJlKuJGMioSihUe0fBu4E9h62/ULPZM6q71UzXGYFZKnSuCLXn8MTjKGDhC6kWT2S0+8L2ETsCvFu1D9p/jO3BPVl/v73w4LsjOWMHbdTGLXz7sKHQQwCsbch6DDHrSLxXLklw 1JBjYKz1 oXBra7h6Uur5QxBSACSq9KmJVUIV0o1WrLy1orORpfTPrsJhhtSRdPcHfX1ilKg5cVX0HDyVjYOyapTJ+vUi9BubfuptJKwoiw5NW7YaBZfcWrQDFtCeORvAJ0CTsKqxhl1PmzUbBEv/0ad+h1wq3Uah2QBNhaKVO+W3ubYZihd6bquUYLW9trABRBbhSqjRhDa9/8kUvZb+qGsEbb76RrPk8DK2IulxwARLcQgSABIJZ2BW8nWK08xvtGnPRnMcNP5nIP14ePcP9bsYJ7Jxcc6X8RIPTEMKzs9pTOVppxIpJH/0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Tetsuo Handa writes: > On 2023/05/22 11:13, Huang, Ying wrote: >>> Any atomic allocation used by KASAN needs to drop __GFP_KSWAPD_RECLAIM bit. >>> Where do we want to drop this bit (in the caller side, or in the callee side)? >> >> Yes. I think we should fix the KASAN. Maybe define a new GFP_XXX >> (instead of GFP_ATOMIC) for debug code? The debug code may be called at >> almost arbitrary places, and wakeup_kswap() isn't safe to be called in >> some situations. > > What do you think about removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC and GFP_NOWAIT? > Recent reports indicate that atomic allocations (GFP_ATOMIC and GFP_NOWAIT) are not safe > enough to think "atomic". They just don't do direct reclaim, but they do take spinlocks. > Removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC and GFP_NOWAIT simplifies locking dependency and > reduces latency of atomic allocations (which is important when called from "atomic" context). > I consider that memory allocations which do not do direct reclaim should be geared towards > less locking dependency. Except debug code, where do you find locking issues for waking up kswapd? > In general, GFP_ATOMIC or GFP_NOWAIT users will not allocate many pages. > It is likely that somebody else tries to allocate memory using __GFP_DIRECT_RECLAIM > right after GFP_ATOMIC or GFP_NOWAIT allocations. We unlikely need to wake kswapd > upon GFP_ATOMIC or GFP_NOWAIT allocations. > > If some GFP_ATOMIC or GFP_NOWAIT users need to allocate many pages, they can add > __GFP_KSWAPD_RECLAIM explicitly; though allocating many pages using GFP_ATOMIC or > GFP_NOWAIT is not recommended from the beginning... >From performance perspective, it's better to wake up kswapd as early as possible. Because it can reduce the possibility of the direct reclaiming, which may case very long latency. Best Regards, Huang, Ying