From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751881AbdLSSZS (ORCPT ); Tue, 19 Dec 2017 13:25:18 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:46473 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751352AbdLSSZP (ORCPT ); Tue, 19 Dec 2017 13:25:15 -0500 X-Google-Smtp-Source: ACJfBotPE3InNcoXk+VKS3o/Xa4bFqW7LDrMlZ8ofTfXnVH0KsU7aK0SoZnqrNVi4OEsWMcpMwtmG9+sLbaoVtQNVEs= MIME-Version: 1.0 In-Reply-To: <20171219173354.GQ3919388@devbig577.frc2.facebook.com> References: <20171219000131.149170-1-shakeelb@google.com> <20171219124908.GS2787@dhcp22.suse.cz> <20171219152444.GP3919388@devbig577.frc2.facebook.com> <20171219173354.GQ3919388@devbig577.frc2.facebook.com> From: Shakeel Butt Date: Tue, 19 Dec 2017 10:25:12 -0800 Message-ID: Subject: Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2 To: Tejun Heo Cc: Michal Hocko , Li Zefan , Roman Gushchin , Vladimir Davydov , Greg Thelen , Johannes Weiner , Hugh Dickins , Andrew Morton , Linux MM , LKML , Cgroups , linux-doc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 19, 2017 at 9:33 AM, Tejun Heo wrote: > Hello, > > On Tue, Dec 19, 2017 at 09:23:29AM -0800, Shakeel Butt wrote: >> To provide consistent memory usage history using the current >> cgroup-v2's 'swap' interface, an additional metric expressing the >> intersection of memory and swap has to be exposed. Basically memsw is >> the union of memory and swap. So, if that additional metric can be > > Exposing anonymous pages with swap backing sounds pretty trivial. > >> used to find the union. However for consistent memory limit >> enforcement, I don't think there is an easy way to use current 'swap' >> interface. > > Can you please go into details on why this is important? I get that > you can't do it as easily w/o memsw but I don't understand why this is > a critical feature. Why is that? > Making the runtime environment, an invariant is very critical to make the management of a job easier whose instances run on different clusters across the world. Some clusters might have different type of swaps installed while some might not have one at all and the availability of the swap can be dynamic (i.e. swap medium outage). So, if users want to run multiple instances of a job across multiple clusters, they should be able to specify the limits of their jobs irrespective of the knowledge of cluster. The best case would be they just submits their jobs without any config and the system figures out the right limit and enforce that. And to figure out the right limit and enforcing it, the consistent memory usage history and consistent memory limit enforcement is very critical. thanks, Shakeel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 5F2876B0069 for ; Tue, 19 Dec 2017 13:25:15 -0500 (EST) Received: by mail-wm0-f70.google.com with SMTP id n13so1554336wmc.3 for ; Tue, 19 Dec 2017 10:25:15 -0800 (PST) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id z64sor884186wmh.26.2017.12.19.10.25.14 for (Google Transport Security); Tue, 19 Dec 2017 10:25:14 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20171219173354.GQ3919388@devbig577.frc2.facebook.com> References: <20171219000131.149170-1-shakeelb@google.com> <20171219124908.GS2787@dhcp22.suse.cz> <20171219152444.GP3919388@devbig577.frc2.facebook.com> <20171219173354.GQ3919388@devbig577.frc2.facebook.com> From: Shakeel Butt Date: Tue, 19 Dec 2017 10:25:12 -0800 Message-ID: Subject: Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2 Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Tejun Heo Cc: Michal Hocko , Li Zefan , Roman Gushchin , Vladimir Davydov , Greg Thelen , Johannes Weiner , Hugh Dickins , Andrew Morton , Linux MM , LKML , Cgroups , linux-doc@vger.kernel.org On Tue, Dec 19, 2017 at 9:33 AM, Tejun Heo wrote: > Hello, > > On Tue, Dec 19, 2017 at 09:23:29AM -0800, Shakeel Butt wrote: >> To provide consistent memory usage history using the current >> cgroup-v2's 'swap' interface, an additional metric expressing the >> intersection of memory and swap has to be exposed. Basically memsw is >> the union of memory and swap. So, if that additional metric can be > > Exposing anonymous pages with swap backing sounds pretty trivial. > >> used to find the union. However for consistent memory limit >> enforcement, I don't think there is an easy way to use current 'swap' >> interface. > > Can you please go into details on why this is important? I get that > you can't do it as easily w/o memsw but I don't understand why this is > a critical feature. Why is that? > Making the runtime environment, an invariant is very critical to make the management of a job easier whose instances run on different clusters across the world. Some clusters might have different type of swaps installed while some might not have one at all and the availability of the swap can be dynamic (i.e. swap medium outage). So, if users want to run multiple instances of a job across multiple clusters, they should be able to specify the limits of their jobs irrespective of the knowledge of cluster. The best case would be they just submits their jobs without any config and the system figures out the right limit and enforce that. And to figure out the right limit and enforcing it, the consistent memory usage history and consistent memory limit enforcement is very critical. thanks, Shakeel -- 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: Shakeel Butt Subject: Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2 Date: Tue, 19 Dec 2017 10:25:12 -0800 Message-ID: References: <20171219000131.149170-1-shakeelb@google.com> <20171219124908.GS2787@dhcp22.suse.cz> <20171219152444.GP3919388@devbig577.frc2.facebook.com> <20171219173354.GQ3919388@devbig577.frc2.facebook.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TgU4la4R+wGXyQ42kCnAIZNWZ3v+5UVW6cl9VCnE2D4=; b=gtE0B0rtSd4sZOR0V0guBYS5HEGqgoqgw0yAnxHkeUDX9S285giLuNR6ja7eFUyom/ ug7VfSYc3K8G62phA+fXZ2Z6qPfACmdVAiMAV+CPxzZTqNMWc18NfIi8Sqoldlf0jlbp cD69v9+Tpya8XD5Y5uo0flQVdsScLyhM/ykXfrfGuSLwA3fBIzkry0wsjH4tgDb6g9pw w89dwDiHBS7yzs77uUqAenptNBMXqhRcp4g8lRUHLPB/ii3kvE+Gz+e6tQ5SYEab2rM1 6x7c3WP+Yh0T3fI3DR98OIOXxdTvYzTm4ZB0Pmf8Uu3LcduVMzSuvwLLaAF7L/UD2FG2 iekg== In-Reply-To: <20171219173354.GQ3919388-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tejun Heo Cc: Michal Hocko , Li Zefan , Roman Gushchin , Vladimir Davydov , Greg Thelen , Johannes Weiner , Hugh Dickins , Andrew Morton , Linux MM , LKML , Cgroups , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On Tue, Dec 19, 2017 at 9:33 AM, Tejun Heo wrote: > Hello, > > On Tue, Dec 19, 2017 at 09:23:29AM -0800, Shakeel Butt wrote: >> To provide consistent memory usage history using the current >> cgroup-v2's 'swap' interface, an additional metric expressing the >> intersection of memory and swap has to be exposed. Basically memsw is >> the union of memory and swap. So, if that additional metric can be > > Exposing anonymous pages with swap backing sounds pretty trivial. > >> used to find the union. However for consistent memory limit >> enforcement, I don't think there is an easy way to use current 'swap' >> interface. > > Can you please go into details on why this is important? I get that > you can't do it as easily w/o memsw but I don't understand why this is > a critical feature. Why is that? > Making the runtime environment, an invariant is very critical to make the management of a job easier whose instances run on different clusters across the world. Some clusters might have different type of swaps installed while some might not have one at all and the availability of the swap can be dynamic (i.e. swap medium outage). So, if users want to run multiple instances of a job across multiple clusters, they should be able to specify the limits of their jobs irrespective of the knowledge of cluster. The best case would be they just submits their jobs without any config and the system figures out the right limit and enforce that. And to figure out the right limit and enforcing it, the consistent memory usage history and consistent memory limit enforcement is very critical. thanks, Shakeel