From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754269AbbFKSrp (ORCPT ); Thu, 11 Jun 2015 14:47:45 -0400 Received: from one.firstfloor.org ([193.170.194.197]:43565 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753169AbbFKSrm (ORCPT ); Thu, 11 Jun 2015 14:47:42 -0400 Date: Thu, 11 Jun 2015 20:47:37 +0200 From: Andi Kleen To: David Ahern Cc: Arnaldo Carvalho de Melo , kan.liang@intel.com, linux-kernel@vger.kernel.org, ying.huang@intel.com, andi@firstfloor.org Subject: Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing Message-ID: <20150611184737.GU19417@two.firstfloor.org> References: <1433922364-22580-1-git-send-email-kan.liang@intel.com> <20150611140614.GC2696@kernel.org> <5579A766.4010504@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5579A766.4010504@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Can you elaborate on an example? I don't see how this can happen > reading a maps file. And it does not read maps for all threads only > thread group leaders. This is with a stress test case that generates lots of small mappings at very high speed and frees them again. So the maps file keeps changing faster than the proc reader can keep it and it can end up with a live lock. -Andi -- ak@linux.intel.com -- Speaking for myself only.