From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755350AbeE2Ib6 (ORCPT ); Tue, 29 May 2018 04:31:58 -0400 Received: from mx2.suse.de ([195.135.220.15]:49187 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751203AbeE2Ibz (ORCPT ); Tue, 29 May 2018 04:31:55 -0400 Date: Tue, 29 May 2018 10:31:53 +0200 From: Michal Hocko To: Shakeel Butt Cc: Vladimir Davydov , Andrew Morton , Greg Thelen , Johannes Weiner , Linux MM , Cgroups , LKML Subject: Re: [PATCH] memcg: force charge kmem counter too Message-ID: <20180529083153.GR27180@dhcp22.suse.cz> References: <20180525185501.82098-1-shakeelb@google.com> <20180526185144.xvh7ejlyelzvqwdb@esperanza> <20180528091110.GG1517@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 28-05-18 10:23:07, Shakeel Butt wrote: > On Mon, May 28, 2018 at 2:11 AM, Michal Hocko wrote: > Though is there a precedence where the broken feature is not fixed > because an alternative is available? Well, I can see how breaking GFP_NOFAIL semantic is problematic, on the other hand we keep saying that kmem accounting in v1 is hard usable and strongly discourage people from using it. Sure we can add the code which handles _this_ particular case but that wouldn't make the whole thing more usable I strongly suspect. Maybe I am wrong and you can provide some specific examples. Is GFP_NOFAIL that common to matter? In any case we should balance between the code maintainability here. Adding more cruft into the allocator path is not free. -- Michal Hocko SUSE Labs