Received: by 10.213.65.68 with SMTP id h4csp1243288imn; Wed, 21 Mar 2018 06:16:13 -0700 (PDT) X-Google-Smtp-Source: AG47ELuqLx6BqD5wca/Njw8xVJ6O0cq2Hepir2S7MaQhjejQ8rilRAP8gq+WjxJllJdCqulAiT49 X-Received: by 2002:a17:902:ac96:: with SMTP id h22-v6mr20361074plr.93.1521638173059; Wed, 21 Mar 2018 06:16:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521638173; cv=none; d=google.com; s=arc-20160816; b=LpOKc6GOt79au1FnViSCrA8QWTzKtOqfrxc+65usk1gCfoAQw6EILARRB/89sL67gR rihL8SzLY1gCPTmyBk2KrpmKR7y9UDq8OWei5B82Aj6DkYLLtXckETc1XuOeHKxHDn70 XZHVqfVd8b6IUUo+W2/x9AfVFfnkL5RMNyAHcdxP1ci146sx1hDYclY+sfxzVwkXu1IY 8OLy2jYFdiM3AQZHRkHnxTw+rbj778ASciqQDeNeZxEI77zbNizeNDILgCV8SMhoi+RT eQnxkNooo6iG04BfG8MtiPiqROAK20qlwtFtCWCSIRAbMwbrJnjyWm/ETu3TzVyqpogw ve/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=hfX+DRX81QF8aUJT2noS28MGuEgDMLsia1kYqgnsbNc=; b=vyYNE1gdQMJkRZdM4JEH6yDMEzfggy+v0TWBhYhWYK7YI5ajSyQ4wktexV+eJNsEmi 9LQB9jRh4KKW9UNzQR4PdBYINVWh1iECJJ7P3bAhgY2PBQXrWneSJJ6F+gXuH3LwkWk3 CpZVHf5/umxjPtA+E8WfzcWMv7j+RlyCllKCd18oAFQXgz1HPPKKBUGblnKlFs1hQ2RE F1G2vD2xT8zre55vQBEnS1Ll4jvcNoMgyAdjzskzHilzOETS6roVBN5fyb1/HaSzIldR UJ6x+qwTza3VEbNsBNvPSO2TTVf6hpCSnxVfGMgIAta5RWTRFADAocxr7/dx1UJleKR1 gFZg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g4si3054653pfm.358.2018.03.21.06.15.58; Wed, 21 Mar 2018 06:16:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751902AbeCUNOz (ORCPT + 99 others); Wed, 21 Mar 2018 09:14:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:44950 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751657AbeCUNOv (ORCPT ); Wed, 21 Mar 2018 09:14:51 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 60126AC4A; Wed, 21 Mar 2018 13:14:50 +0000 (UTC) Date: Wed, 21 Mar 2018 14:14:49 +0100 From: Michal Hocko To: Yang Shi Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section Message-ID: <20180321131449.GN23100@dhcp22.suse.cz> References: <1521581486-99134-1-git-send-email-yang.shi@linux.alibaba.com> <1521581486-99134-2-git-send-email-yang.shi@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1521581486-99134-2-git-send-email-yang.shi@linux.alibaba.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 21-03-18 05:31:19, Yang Shi wrote: > When running some mmap/munmap scalability tests with large memory (i.e. > > 300GB), the below hung task issue may happen occasionally. > > INFO: task ps:14018 blocked for more than 120 seconds. > Tainted: G E 4.9.79-009.ali3000.alios7.x86_64 #1 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this > message. > ps D 0 14018 1 0x00000004 > ffff885582f84000 ffff885e8682f000 ffff880972943000 ffff885ebf499bc0 > ffff8828ee120000 ffffc900349bfca8 ffffffff817154d0 0000000000000040 > 00ffffff812f872a ffff885ebf499bc0 024000d000948300 ffff880972943000 > Call Trace: > [] ? __schedule+0x250/0x730 > [] schedule+0x36/0x80 > [] rwsem_down_read_failed+0xf0/0x150 > [] call_rwsem_down_read_failed+0x18/0x30 > [] down_read+0x20/0x40 > [] proc_pid_cmdline_read+0xd9/0x4e0 Slightly off-topic: Btw. this sucks as well. Do we really need to take mmap_sem here? Do any of arg_start = mm->arg_start; arg_end = mm->arg_end; env_start = mm->env_start; env_end = mm->env_end; change after exec or while the pid is already visible in proc? If yes maybe we can use a dedicated lock. -- Michal Hocko SUSE Labs