From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756423AbcEaVGN (ORCPT ); Tue, 31 May 2016 17:06:13 -0400 Received: from mga01.intel.com ([192.55.52.88]:48980 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751375AbcEaVGM (ORCPT ); Tue, 31 May 2016 17:06:12 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,397,1459839600"; d="scan'208";a="992504890" Date: Tue, 31 May 2016 17:13:08 -0400 From: Keith Busch To: Tejun Heo Cc: linux-mm@kvack.org, LKML Subject: Re: [PATCH] mm/swap: lru drain on memory reclaim workqueue Message-ID: <20160531211308.GE24107@localhost.localdomain> References: <1464727815-13073-1-git-send-email-keith.busch@intel.com> <20160531210116.GA14868@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160531210116.GA14868@mtj.duckdns.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 31, 2016 at 05:01:16PM -0400, Tejun Heo wrote: > So, WQ_MEM_RECLAIM on a shared workqueue doesn't make much sense. > That flag guarantees single concurrency level to the workqueue. How > would multiple users of a shared workqueue coordinate around that? > What prevents one events_mem_unbound user from depending on, say, > draining lru? If lru draining requires a rescuer to guarantee forward > progress under memory pressure, that rescuer worker must be dedicated > for that purpose and can't be shared. Gotchya, that fixes my understanding on the rescuer thread operation. In this case, could we revive your previous proposal for consideration?