From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756538Ab3EQRp5 (ORCPT ); Fri, 17 May 2013 13:45:57 -0400 Received: from mail-pb0-f52.google.com ([209.85.160.52]:53663 "EHLO mail-pb0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756480Ab3EQRpz convert rfc822-to-8bit (ORCPT ); Fri, 17 May 2013 13:45:55 -0400 MIME-Version: 1.0 In-Reply-To: References: <1368431172-6844-1-git-send-email-mhocko@suse.cz> <1368431172-6844-2-git-send-email-mhocko@suse.cz> <20130517160247.GA10023@cmpxchg.org> <20130517165712.GB12632@mtj.dyndns.org> Date: Fri, 17 May 2013 10:45:54 -0700 X-Google-Sender-Auth: r33Xvo1uaGbbrnR9aWWOWt8RIXU Message-ID: Subject: Re: [patch v3 -mm 1/3] memcg: integrate soft reclaim tighter with zone shrinking code From: Tejun Heo To: Johannes Weiner Cc: Michal Hocko , Andrew Morton , "linux-mm@kvack.org" , Cgroups , lkml , KAMEZAWA Hiroyuki , Ying Han , Hugh Dickins , Glauber Costa , Michel Lespinasse , Greg Thelen , Balbir Singh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Fri, May 17, 2013 at 10:27 AM, Johannes Weiner wrote: >>Hmmm... if the iteration is the problem, it shouldn't be difficult to >>build list of children which should be iterated. Would that make it >>acceptable? > > You mean, a separate structure that tracks which groups are in excess of the limit? Like the current tree? :) Heh, yeah, realized that after writing it but it can be something much simpler. ie. just linked list of children with soft limit configured. > Kidding aside, yes, that would be better, and an unsorted list would probably be enough for the global case. Yeap. > To support target reclaim soft limits later on, we could maybe propagate tags upwards the cgroup tree when a group is in excess so that reclaim can be smarter about which subtrees to test for soft limits and which to skip during the soft limit pass. The no-softlimit-set-anywhere case is then only a single tag test in the root cgroup. > > But starting with the list would be simple enough, delete a bunch of code, come with the same performance improvements etc. Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx133.postini.com [74.125.245.133]) by kanga.kvack.org (Postfix) with SMTP id C69A66B0032 for ; Fri, 17 May 2013 13:45:55 -0400 (EDT) Received: by mail-pa0-f44.google.com with SMTP id jh10so3782741pab.31 for ; Fri, 17 May 2013 10:45:55 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1368431172-6844-1-git-send-email-mhocko@suse.cz> <1368431172-6844-2-git-send-email-mhocko@suse.cz> <20130517160247.GA10023@cmpxchg.org> <20130517165712.GB12632@mtj.dyndns.org> Date: Fri, 17 May 2013 10:45:54 -0700 Message-ID: Subject: Re: [patch v3 -mm 1/3] memcg: integrate soft reclaim tighter with zone shrinking code From: Tejun Heo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Johannes Weiner Cc: Michal Hocko , Andrew Morton , "linux-mm@kvack.org" , Cgroups , lkml , KAMEZAWA Hiroyuki , Ying Han , Hugh Dickins , Glauber Costa , Michel Lespinasse , Greg Thelen , Balbir Singh Hello, On Fri, May 17, 2013 at 10:27 AM, Johannes Weiner wrot= e: >>Hmmm... if the iteration is the problem, it shouldn't be difficult to >>build list of children which should be iterated. Would that make it >>acceptable? > > You mean, a separate structure that tracks which groups are in excess of = the limit? Like the current tree? :) Heh, yeah, realized that after writing it but it can be something much simpler. ie. just linked list of children with soft limit configured. > Kidding aside, yes, that would be better, and an unsorted list would prob= ably be enough for the global case. Yeap. > To support target reclaim soft limits later on, we could maybe propagate = tags upwards the cgroup tree when a group is in excess so that reclaim can = be smarter about which subtrees to test for soft limits and which to skip d= uring the soft limit pass. The no-softlimit-set-anywhere case is then only= a single tag test in the root cgroup. > > But starting with the list would be simple enough, delete a bunch of code= , come with the same performance improvements etc. 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: [patch v3 -mm 1/3] memcg: integrate soft reclaim tighter with zone shrinking code Date: Fri, 17 May 2013 10:45:54 -0700 Message-ID: References: <1368431172-6844-1-git-send-email-mhocko@suse.cz> <1368431172-6844-2-git-send-email-mhocko@suse.cz> <20130517160247.GA10023@cmpxchg.org> <20130517165712.GB12632@mtj.dyndns.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EocGuCEiGWzgXNnNen9CIMTKgmqP8xfFrgh1/iO1+D4=; b=L1Rp+mgHg/6DJfOLR6KHe2BeKypPmGADNbfGUPzXe5lY7jKkichzHzVbCa6Y+BH1Fj /VWR5Cgm2rXfECF+kwMw3K9aC1hYAeL74ahqtOqXBwjqR1z+GkpNbo9oQrrqJdl7r5TZ YsolSH3avOnWRyPAyAc4lI6xl8Nax4OAvfIXARhsY9kzlDuekDOccb9vTEAE9+Mlf4bm X1FhC346t/8h8gOnovR3d1iuAh/axWPneos8Q9vVuqEb0GPaxCDuMyqFCyzZ0d/fHnbB AHFQMLWa5tYOXJi7fQL/i7aALJPPAgkPUmkc8wAlUQPTSmVlX7FcVCfOKd8q/0+9tvCU ZVsw== In-Reply-To: Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Johannes Weiner Cc: Michal Hocko , Andrew Morton , "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org" , Cgroups , lkml , KAMEZAWA Hiroyuki , Ying Han , Hugh Dickins , Glauber Costa , Michel Lespinasse , Greg Thelen , Balbir Singh Hello, On Fri, May 17, 2013 at 10:27 AM, Johannes Weiner wrote: >>Hmmm... if the iteration is the problem, it shouldn't be difficult to >>build list of children which should be iterated. Would that make it >>acceptable? > > You mean, a separate structure that tracks which groups are in excess of the limit? Like the current tree? :) Heh, yeah, realized that after writing it but it can be something much simpler. ie. just linked list of children with soft limit configured. > Kidding aside, yes, that would be better, and an unsorted list would probably be enough for the global case. Yeap. > To support target reclaim soft limits later on, we could maybe propagate tags upwards the cgroup tree when a group is in excess so that reclaim can be smarter about which subtrees to test for soft limits and which to skip during the soft limit pass. The no-softlimit-set-anywhere case is then only a single tag test in the root cgroup. > > But starting with the list would be simple enough, delete a bunch of code, come with the same performance improvements etc. Thanks. -- tejun