From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757928AbcHCMxz (ORCPT ); Wed, 3 Aug 2016 08:53:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33524 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753669AbcHCMxw (ORCPT ); Wed, 3 Aug 2016 08:53:52 -0400 Date: Wed, 3 Aug 2016 08:53:25 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Michal Hocko cc: NeilBrown , Tetsuo Handa , LKML , linux-mm@kvack.org, dm-devel@redhat.com, Mel Gorman , David Rientjes , Ondrej Kozina , Andrew Morton Subject: Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks In-Reply-To: <20160728071711.GB31860@dhcp22.suse.cz> Message-ID: References: <1468831164-26621-1-git-send-email-mhocko@kernel.org> <1468831285-27242-1-git-send-email-mhocko@kernel.org> <1468831285-27242-2-git-send-email-mhocko@kernel.org> <87oa5q5abi.fsf@notabene.neil.brown.name> <20160722091558.GF794@dhcp22.suse.cz> <878twt5i1j.fsf@notabene.neil.brown.name> <20160725083247.GD9401@dhcp22.suse.cz> <87lh0n4ufs.fsf@notabene.neil.brown.name> <20160727182411.GE21859@dhcp22.suse.cz> <87eg6e4vhc.fsf@notabene.neil.brown.name> <20160728071711.GB31860@dhcp22.suse.cz> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 03 Aug 2016 12:53:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 28 Jul 2016, Michal Hocko wrote: > > >> I think we'd end up with cleaner code if we removed the cute-hacks. And > > >> we'd be able to use 6 more GFP flags!! (though I do wonder if we really > > >> need all those 26). > > > > > > Well, maybe we are able to remove those hacks, I wouldn't definitely > > > be opposed. But right now I am not even convinced that the mempool > > > specific gfp flags is the right way to go. > > > > I'm not suggesting a mempool-specific gfp flag. I'm suggesting a > > transient-allocation gfp flag, which would be quite useful for mempool. > > > > Can you give more details on why using a gfp flag isn't your first choice > > for guiding what happens when the system is trying to get a free page > > :-? > > If we get rid of throttle_vm_writeout then I guess it might turn out to > be unnecessary. There are other places which will still throttle but I > believe those should be kept regardless of who is doing the allocation > because they are helping the LRU scanning sane. I might be wrong here > and bailing out from the reclaim rather than waiting would turn out > better for some users but I would like to see whether the first approach > works reasonably well. If we are swapping to a dm-crypt device, the dm-crypt device is congested and the underlying block device is not congested, we should not throttle mempool allocations made from the dm-crypt workqueue. Not even a little bit. So, I think, mempool_alloc should set PF_NO_THROTTLE (or __GFP_NO_THROTTLE). Mikulas > -- > Michal Hocko > SUSE Labs > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) by kanga.kvack.org (Postfix) with ESMTP id 74BC66B0005 for ; Wed, 3 Aug 2016 08:53:29 -0400 (EDT) Received: by mail-ua0-f198.google.com with SMTP id n59so276618991uan.1 for ; Wed, 03 Aug 2016 05:53:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id w3si2064434qkc.12.2016.08.03.05.53.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2016 05:53:28 -0700 (PDT) Date: Wed, 3 Aug 2016 08:53:25 -0400 (EDT) From: Mikulas Patocka Subject: Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks In-Reply-To: <20160728071711.GB31860@dhcp22.suse.cz> Message-ID: References: <1468831164-26621-1-git-send-email-mhocko@kernel.org> <1468831285-27242-1-git-send-email-mhocko@kernel.org> <1468831285-27242-2-git-send-email-mhocko@kernel.org> <87oa5q5abi.fsf@notabene.neil.brown.name> <20160722091558.GF794@dhcp22.suse.cz> <878twt5i1j.fsf@notabene.neil.brown.name> <20160725083247.GD9401@dhcp22.suse.cz> <87lh0n4ufs.fsf@notabene.neil.brown.name> <20160727182411.GE21859@dhcp22.suse.cz> <87eg6e4vhc.fsf@notabene.neil.brown.name> <20160728071711.GB31860@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: NeilBrown , Tetsuo Handa , LKML , linux-mm@kvack.org, dm-devel@redhat.com, Mel Gorman , David Rientjes , Ondrej Kozina , Andrew Morton On Thu, 28 Jul 2016, Michal Hocko wrote: > > >> I think we'd end up with cleaner code if we removed the cute-hacks. And > > >> we'd be able to use 6 more GFP flags!! (though I do wonder if we really > > >> need all those 26). > > > > > > Well, maybe we are able to remove those hacks, I wouldn't definitely > > > be opposed. But right now I am not even convinced that the mempool > > > specific gfp flags is the right way to go. > > > > I'm not suggesting a mempool-specific gfp flag. I'm suggesting a > > transient-allocation gfp flag, which would be quite useful for mempool. > > > > Can you give more details on why using a gfp flag isn't your first choice > > for guiding what happens when the system is trying to get a free page > > :-? > > If we get rid of throttle_vm_writeout then I guess it might turn out to > be unnecessary. There are other places which will still throttle but I > believe those should be kept regardless of who is doing the allocation > because they are helping the LRU scanning sane. I might be wrong here > and bailing out from the reclaim rather than waiting would turn out > better for some users but I would like to see whether the first approach > works reasonably well. If we are swapping to a dm-crypt device, the dm-crypt device is congested and the underlying block device is not congested, we should not throttle mempool allocations made from the dm-crypt workqueue. Not even a little bit. So, I think, mempool_alloc should set PF_NO_THROTTLE (or __GFP_NO_THROTTLE). Mikulas > -- > Michal Hocko > SUSE Labs > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org