From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96007C3815B for ; Mon, 20 Apr 2020 16:13:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 057482074F for ; Mon, 20 Apr 2020 16:13:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="RExdkPNl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 057482074F Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 653F08E0005; Mon, 20 Apr 2020 12:13:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 604D18E0003; Mon, 20 Apr 2020 12:13:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CCDA8E0005; Mon, 20 Apr 2020 12:13:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 339288E0003 for ; Mon, 20 Apr 2020 12:13:08 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E27EB181AEF10 for ; Mon, 20 Apr 2020 16:13:07 +0000 (UTC) X-FDA: 76728727614.29.class88_1b453f0ebff58 X-HE-Tag: class88_1b453f0ebff58 X-Filterd-Recvd-Size: 6687 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Apr 2020 16:13:07 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id f8so8434406lfe.12 for ; Mon, 20 Apr 2020 09:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dfnbaRIAsllucTJQqQcadbN8F/8KsJlw6FggVLdXySc=; b=RExdkPNluxT8pywLn0mtot2iKfm78aU0yPMPN3JNMBc8hy69Jb74NTwJ9/mDzYEJJM 70Vy46SFhMEz2tYTGzL4RnmZPsCYPMcBs/f/MnY39ZeU6R/nbXjgZYtKn50ehe9Tm5yB 1Yn4Kt6WA2bvJ2Rc5ayjUpyoiPNE1HQRcpCD/xcLLH9T7yVmC2ri9Vs69gIQeqmMGatc zorcuCdFsSoQfj2FhDBVAE2NB6FURZVGBAtPIf5fTiTG8dwbldca3AFT/xnz+egLIwHV KV5uGCstV5LzALGPFVaNN8GJO4P5HygcgphYyX1uw17aG4HScrTAed8yooDnTtWscXUm M2Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dfnbaRIAsllucTJQqQcadbN8F/8KsJlw6FggVLdXySc=; b=EMp130JjbipIPjU8/j18vrp5jsE44o/TIEDCC+DbdzhkEqk0qIpwl1jMsbJnyHRh9x OjeYWdnNZ+c2JXlQ32JXB1QKLV5D/3vCkYoQ5OYQFVxmJ5aSIHDQMxia8ojdxBgRJ8nc ee5bPyNfZ2y/Y6WE2owZEog/kfyZy0sbCr1H5gjdjqBZP1ArMb+ifaNSHUtVolaKlo90 ELLVL9KKATK0vEyevi/0gNdDCNVxMIazcvd/DgYiZKwmlkBs3IMOsPRzOzCvbjahiiHu Has66wQDVqOQfE7QUTqlfOsyKb91C0jrvK/08Rhda3k00vpL/cgodLR3zrFkAIIY8Cva VZKg== X-Gm-Message-State: AGi0Pua3IY1stqOSEugUVzxopB96e840TarnmNs6Z20M2CYnUkNFEg/2 g93RQHmzr7w8pcX5qqetRL6tGAmQuH0qT8cWLlo89Q== X-Google-Smtp-Source: APiQypIf1MKwdomyP3DPdhcV5nrvw6pQDznQwTjXvKopnIFyyUqZkLy8aJq7yDTI2swTFEc92+/eHfIDBzFRJR8XC68= X-Received: by 2002:a19:c1d3:: with SMTP id r202mr10815845lff.216.1587399185435; Mon, 20 Apr 2020 09:13:05 -0700 (PDT) MIME-Version: 1.0 References: <20200417010617.927266-1-kuba@kernel.org> <20200417162355.GA43469@mtj.thefacebook.com> <20200417173615.GB43469@mtj.thefacebook.com> <20200417193539.GC43469@mtj.thefacebook.com> <20200417225941.GE43469@mtj.thefacebook.com> In-Reply-To: <20200417225941.GE43469@mtj.thefacebook.com> From: Shakeel Butt Date: Mon, 20 Apr 2020 09:12:54 -0700 Message-ID: Subject: Re: [PATCH 0/3] memcg: Slow down swap allocation as the available space gets depleted To: Tejun Heo Cc: Jakub Kicinski , Andrew Morton , Linux MM , Kernel Team , Johannes Weiner , Chris Down , Cgroups Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Tejun, On Fri, Apr 17, 2020 at 3:59 PM Tejun Heo wrote: > > Hello, Shakeel. > > On Fri, Apr 17, 2020 at 02:51:09PM -0700, Shakeel Butt wrote: > > > > In this example does 'B' have memory.high and memory.max set and by A > > > > > > B doesn't have anything set. > > > > > > > having no other restrictions, I am assuming you meant unlimited high > > > > and max for A? Can 'A' use memory.min? > > > > > > Sure, it can but 1. the purpose of the example is illustrating the > > > imcompleteness of the existing mechanism > > > > I understand but is this a real world configuration people use and do > > we want to support the scenario where without setting high/max, the > > kernel still guarantees the isolation. > > Yes, that's the configuration we're deploying fleet-wide and at least the > direction I'm gonna be pushing towards for reasons of generality and ease of > use. > > Here's an example to illustrate the point - consider distros or upstream > desktop environments wanting to provide basic resource configuration to > protect user sessions and critical system services needed for user > interaction by default. That is something which is clearly and immediately > useful but also is extremely challenging to achieve with limits. > > There are no universally good enough upper limits. Any one number is gonna > be both too high to guarantee protection and too low for use cases which > legitimately need that much memory. That's because the upper limits aren't > work-conserving and have a high chance of doing harm when misconfigured > making figuring out the correct configuration almost impossible with > per-use-case manual tuning. > > The whole idea behind memory.low and related efforts is resolving that > problem by making memory control more work-conserving and forgiving, so that > users can say something like "I want the user session to have at least 25% > memory protected if needed and possible" and get most of the benefits of > carefully crafted configuration. We're already deploying such configuration > and it works well enough for a wide variety of workloads. > I got the high level vision but I am very skeptical that in terms of memory and performance isolation this can provide anything better than best effort QoS which might be good enough for desktop users. However, for a server environment where multiple latency sensitive interactive jobs are co-hosted with multiple batch jobs and the machine's memory may be over-committed, this is a recipe for disaster. The only scenario where I think it might work is if there is only one job running on the machine. I do agree that finding the right upper limit is a challenge. For us, we have two types of users, first, who knows exactly how much resources they want and second ask us to set the limits appropriately. We have a ML/history based central system to dynamically set and adjust limits for jobs of such users. Coming back to this path series, to me, it seems like the patch series is contrary to the vision you are presenting. Though the users are not setting memory.[high|max] but they are setting swap.max and this series is asking to set one more tunable i.e. swap.high. The approach more consistent with the presented vision is to throttle or slow down the allocators when the system swap is near full and there is no need to set swap.max or swap.high. thanks, Shakeel