From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e38.co.us.ibm.com ([32.97.110.159]:35907 "EHLO e38.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751627AbcBOGCA (ORCPT ); Mon, 15 Feb 2016 01:02:00 -0500 Received: from localhost by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 14 Feb 2016 23:01:58 -0700 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 3FBC119D8042 for ; Sun, 14 Feb 2016 22:49:53 -0700 (MST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u1F61smq32964774 for ; Mon, 15 Feb 2016 06:01:54 GMT Received: from d01av01.pok.ibm.com (localhost [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u1F61qIS020810 for ; Mon, 15 Feb 2016 01:01:54 -0500 Date: Sun, 14 Feb 2016 22:01:55 -0800 From: "Paul E. McKenney" To: Linus Torvalds Cc: Jeff Layton , Eryu Guan , linux-fsdevel , Jan Kara , Andrew Morton Subject: Re: [BUG] inotify_add_watch/inotify_rm_watch loops trigger oom Message-ID: <20160215060155.GV6719@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20160214083543.GC29898@eguan.usersys.redhat.com> <20160214093931.40da9afa@tlielax.poochiereds.net> <20160215010238.GT6719@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Feb 14, 2016 at 06:33:25PM -0800, Linus Torvalds wrote: > On Sun, Feb 14, 2016 at 5:02 PM, Paul E. McKenney > wrote: > > > > One thought would be to add an "emergency mode" to SRCU similar to that > > already in RCU. Something to the effect that if the current list of > > callbacks is going to take more than a second to drain at the configured > > per-jiffy rate, just process them without waiting. > > > > Would that help in this case, or am I missing something about the > > reproducer? > > Let's see if we can avoid srcu callbacks entirely as per Jeff, that > would be the best option. Agreed, no point in adding complication without use cases. Thanx, Paul