From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762763AbbA3QH2 (ORCPT ); Fri, 30 Jan 2015 11:07:28 -0500 Received: from mail-qc0-f174.google.com ([209.85.216.174]:59111 "EHLO mail-qc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758967AbbA3QH0 (ORCPT ); Fri, 30 Jan 2015 11:07:26 -0500 Date: Fri, 30 Jan 2015 11:07:22 -0500 From: Tejun Heo To: Greg Thelen Cc: Johannes Weiner , Michal Hocko , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jan Kara , Dave Chinner , Jens Axboe , Christoph Hellwig , Li Zefan , hughd@google.com, Konstantin Khebnikov Subject: Re: [RFC] Making memcg track ownership per address_space or anon_vma Message-ID: <20150130160722.GA26111@htj.dyndns.org> References: <20150130044324.GA25699@htj.dyndns.org> <20150130062737.GB25699@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150130062737.GB25699@htj.dyndns.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 Hey, again. On Fri, Jan 30, 2015 at 01:27:37AM -0500, Tejun Heo wrote: > The previous behavior was pretty unpredictable in terms of shared file > ownership too. I wonder whether the better thing to do here is either > charging cases like this to the common ancestor or splitting the > charge equally among the accessors, which might be doable for ro > files. I've been thinking more about this. It's true that doing per-page association allows for avoiding confronting the worst side effects of inode sharing head-on, but it is a tradeoff with fairly weak justfications. The only thing we're gaining is side-stepping the blunt of the problem in an awkward manner and the loss of clarity in taking this compromised position has nasty ramifications when we try to connect it with the rest of the world. I could be missing something major but the more I think about it, it looks to me that the right thing to do here is accounting per-inode and charging shared inodes to the nearest common ancestor. The resulting behavior would be way more logical and predicatable than the current one, which would make it straight forward to integrate memcg with blkcg and writeback. One of the problems that I can think of off the top of my head is that it'd involve more regular use of charge moving; however, this is an operation which is per-inode rather than per-page and still gonna be fairly infrequent. Another one is that if we move memcg over to this behavior, it's likely to affect the behavior on the traditional hierarchies too as we sure as hell don't want to switch between the two major behaviors dynamically but given that behaviors on inode sharing aren't very well supported yet, this can be an acceptable change. Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by kanga.kvack.org (Postfix) with ESMTP id 563A26B0032 for ; Fri, 30 Jan 2015 11:07:26 -0500 (EST) Received: by mail-qg0-f41.google.com with SMTP id q108so38752039qgd.0 for ; Fri, 30 Jan 2015 08:07:26 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com. [2607:f8b0:400d:c01::22b]) by mx.google.com with ESMTPS id d35si14645638qgf.4.2015.01.30.08.07.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Jan 2015 08:07:25 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id s11so21172952qcv.2 for ; Fri, 30 Jan 2015 08:07:25 -0800 (PST) Date: Fri, 30 Jan 2015 11:07:22 -0500 From: Tejun Heo Subject: Re: [RFC] Making memcg track ownership per address_space or anon_vma Message-ID: <20150130160722.GA26111@htj.dyndns.org> References: <20150130044324.GA25699@htj.dyndns.org> <20150130062737.GB25699@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150130062737.GB25699@htj.dyndns.org> Sender: owner-linux-mm@kvack.org List-ID: To: Greg Thelen Cc: Johannes Weiner , Michal Hocko , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jan Kara , Dave Chinner , Jens Axboe , Christoph Hellwig , Li Zefan , hughd@google.com, Konstantin Khebnikov Hey, again. On Fri, Jan 30, 2015 at 01:27:37AM -0500, Tejun Heo wrote: > The previous behavior was pretty unpredictable in terms of shared file > ownership too. I wonder whether the better thing to do here is either > charging cases like this to the common ancestor or splitting the > charge equally among the accessors, which might be doable for ro > files. I've been thinking more about this. It's true that doing per-page association allows for avoiding confronting the worst side effects of inode sharing head-on, but it is a tradeoff with fairly weak justfications. The only thing we're gaining is side-stepping the blunt of the problem in an awkward manner and the loss of clarity in taking this compromised position has nasty ramifications when we try to connect it with the rest of the world. I could be missing something major but the more I think about it, it looks to me that the right thing to do here is accounting per-inode and charging shared inodes to the nearest common ancestor. The resulting behavior would be way more logical and predicatable than the current one, which would make it straight forward to integrate memcg with blkcg and writeback. One of the problems that I can think of off the top of my head is that it'd involve more regular use of charge moving; however, this is an operation which is per-inode rather than per-page and still gonna be fairly infrequent. Another one is that if we move memcg over to this behavior, it's likely to affect the behavior on the traditional hierarchies too as we sure as hell don't want to switch between the two major behaviors dynamically but given that behaviors on inode sharing aren't very well supported yet, this can be an acceptable change. Thanks. -- tejun -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [RFC] Making memcg track ownership per address_space or anon_vma Date: Fri, 30 Jan 2015 11:07:22 -0500 Message-ID: <20150130160722.GA26111@htj.dyndns.org> References: <20150130044324.GA25699@htj.dyndns.org> <20150130062737.GB25699@htj.dyndns.org> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=dLVdT0bD0RxTLwRZKDVmf1uWJ5gHkhuKQnsEt2qAXSk=; b=PHiF69Mr0x6zFQ0yGD7SbpQgrFwO3v0hkTASgmMzUCopU9v5J6Fkq3Wth2Zo4Z37CV Q14esaaFMzoRwBlq8TSC9PDATV8Xv1dF1lGq9//UA15pbk36P2gFyfrSWSHk6g++kN60 DuMAvz8kbbboJfy+FslER6SHdmxUiDimo765vxkvRdonjdAwbhDwra7EeVmRhboBfC3T ReBbG2++OASKCip2fD4rWh9zgFzrajI4Hl6TnQyy+WdeuNf/HwRjWKnCGp6KU01hChSo 7huKpPVI3y0rBn6W0bdxgSeEEZitHAoV2pMCgl6u7BVwOxn9wEa5Lm+jYLdVr+x/WziG mWJg== Content-Disposition: inline In-Reply-To: <20150130062737.GB25699-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Greg Thelen Cc: Johannes Weiner , Michal Hocko , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jan Kara , Dave Chinner , Jens Axboe , Christoph Hellwig , Li Zefan , hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, Konstantin Khebnikov Hey, again. On Fri, Jan 30, 2015 at 01:27:37AM -0500, Tejun Heo wrote: > The previous behavior was pretty unpredictable in terms of shared file > ownership too. I wonder whether the better thing to do here is either > charging cases like this to the common ancestor or splitting the > charge equally among the accessors, which might be doable for ro > files. I've been thinking more about this. It's true that doing per-page association allows for avoiding confronting the worst side effects of inode sharing head-on, but it is a tradeoff with fairly weak justfications. The only thing we're gaining is side-stepping the blunt of the problem in an awkward manner and the loss of clarity in taking this compromised position has nasty ramifications when we try to connect it with the rest of the world. I could be missing something major but the more I think about it, it looks to me that the right thing to do here is accounting per-inode and charging shared inodes to the nearest common ancestor. The resulting behavior would be way more logical and predicatable than the current one, which would make it straight forward to integrate memcg with blkcg and writeback. One of the problems that I can think of off the top of my head is that it'd involve more regular use of charge moving; however, this is an operation which is per-inode rather than per-page and still gonna be fairly infrequent. Another one is that if we move memcg over to this behavior, it's likely to affect the behavior on the traditional hierarchies too as we sure as hell don't want to switch between the two major behaviors dynamically but given that behaviors on inode sharing aren't very well supported yet, this can be an acceptable change. Thanks. -- tejun