Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp3938259pxb; Tue, 7 Sep 2021 10:46:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy5M7ihiILeuFhLUALWpejnou6Xh5tojWXrqj8Dwx9LnHQnlKZ2apjYxY5HfmcN2H0GzD0p X-Received: by 2002:a50:9511:: with SMTP id u17mr710573eda.100.1631036787842; Tue, 07 Sep 2021 10:46:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631036787; cv=none; d=google.com; s=arc-20160816; b=YxTkadKUwhvcTTgEL2rUVkclidmtVoO66UWBcoiPPX2Ey8DHCVeubALO6kOm0tFE53 lg6s7AfqPxlXSF5FpFQbILha52g8l8+jekiwK3HEOB4oMAjuDWq7eitYzMdhe4zZYbhY ebpwcSrUOfXFZKrBuK58KJKFTG4RMzhkSnHcLK50o0es2SoZFHMhX6HKezSi2WyUSxCh 5Kvp7nnJrv2CfkCA6uiCz2um0fVTsaypV6/5XslWKXDEBa90u+SPGREVv8ac87lkwDm1 rsQBfIjIEl7Ile/6pAwe0ZR5M+QZ4QwTHAdGHnTDsaUFfofGHggZYPDxwxWG52jIcf+R 71CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=3ygh4GOZWLd5mBSV3Iad8I8xqR7eNAaxHPjU7vNMPOU=; b=ufaleHfTDkU64Sbyd4U3RCvnR2ldUpI8IXPS+nN0kSgZArTCN9xAlKQFyOXFMTGzvQ Gzx+31GhZu/Hl6yq+n3xiLnjeBEUrhGLqzqlAPMX+6ml1pKsGnzn0vBfVi4sHG9zAeTx KvuBfiZwl4EXrgU6IgsvoR1+KFAiWxnrVNqY8tt8NN2hOrZTike2quHc4VdPafQrRfUA zTonVo270xTAXpXwHu3vKSrLkpqrzWGkkFCVVc82twXpOGUpNKcSrsSSSFT2+kYyrIqD u3RpipGZe2BtUJiQnClw1wJmheTCn1hlZBWhYbb9I+GCGaLfHD5J7y22bzb4wCA01NDK DTWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=BdOSnh3Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gn14si11493061ejc.279.2021.09.07.10.46.02; Tue, 07 Sep 2021 10:46:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=BdOSnh3Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345651AbhIGRTd (ORCPT + 99 others); Tue, 7 Sep 2021 13:19:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233525AbhIGRTc (ORCPT ); Tue, 7 Sep 2021 13:19:32 -0400 Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3E54C061575 for ; Tue, 7 Sep 2021 10:18:25 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id a13so13855618iol.5 for ; Tue, 07 Sep 2021 10:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3ygh4GOZWLd5mBSV3Iad8I8xqR7eNAaxHPjU7vNMPOU=; b=BdOSnh3Yo+bCUdlO5P/MnpYyvSTXL4z4halCF9yiF5plTwr1RtNNQ374niih80JxoN torcbfYXXAiS/H0OZ7gMh46XhOPc7lX6MI7zkh+mFDjd+1EyFwlDD3KoZX1asHNN8uFf 5mBFHaV/+76OMldtIWUAcUROFSDVcWlpWxnSJuQ53ZkQ+NXg5tyjfc+UsbTXfKJUAd/s zQI/uEr2DEG2xzM1jjVHBlo3l3vcACDk+MIURNVPOLBhSdfUUyrUomO5NlkAeGn/8/zs aaB+IcFOoko2uCmhSXqsyoXG/kqSeHPYuO7Xa4TZtLKLbEQQc84EcHP0p2tQ56vo+bFc BcJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3ygh4GOZWLd5mBSV3Iad8I8xqR7eNAaxHPjU7vNMPOU=; b=F17bItBerkbcuYTay1UN2TwWeUf2Vr9Z9QGhW4AhrUIdW8qB551JqH4KAekVRelGKm 49h25ExbQ3/+LIj9gPaTZep2dBB+K2VYVFhWba2abuEM5OYaZwKt5aG2DOwuf+mfa5Ne ekHL8YryufTx3Xw9tgYUUfWfw7acQm8vFolYFWnch9gX4/GrvEcR+nF0Iplo9nspDoSk VTl9AzAaf6i3NRm7lOqtRyJb845u3XWZslMsKbAcuu4wB+Cqp1KQr1OxBAMeYlAv9C3p YoS4b19ivXE0e0dZa6MP7uxWcEJmtU3oSfDDQOo+XZXUuX5P5fYHfQjcm/uw0D8p7+md QLBw== X-Gm-Message-State: AOAM533NGyfE9gj8fa1FeC9YFpLEVAmJWy0BHyK5jwnqdsqtDzMR9FME hYHDy9TpdkG8ATajcs64tZ/r8g== X-Received: by 2002:a6b:f203:: with SMTP id q3mr14797737ioh.32.1631035105204; Tue, 07 Sep 2021 10:18:25 -0700 (PDT) Received: from [192.168.1.30] ([207.135.234.126]) by smtp.gmail.com with ESMTPSA id n11sm6479229ilq.21.2021.09.07.10.18.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Sep 2021 10:18:24 -0700 (PDT) Subject: Re: [memcg] 0f12156dff: will-it-scale.per_process_ops -33.6% regression To: Tejun Heo , Roman Gushchin Cc: Linus Torvalds , kernel test robot , Vasily Averin , Shakeel Butt , Alexander Viro , Alexey Dobriyan , Andrei Vagin , Borislav Petkov , Borislav Petkov , Christian Brauner , Dmitry Safonov <0x7f454c46@gmail.com>, "Eric W. Biederman" , Greg Kroah-Hartman , "H. Peter Anvin" , Ingo Molnar , "J. Bruce Fields" , Jeff Layton , Jiri Slaby , Johannes Weiner , Kirill Tkhai , Michal Hocko , Oleg Nesterov , Serge Hallyn , Thomas Gleixner , Vladimir Davydov , Yutian Yang , Zefan Li , Andrew Morton , LKML , lkp@lists.01.org, kernel test robot , "Huang, Ying" , Feng Tang , Zhengjun Xing References: <20210907150757.GE17617@xsang-OptiPlex-9020> <774dee70-69bd-9f95-d197-4cff83e4e633@kernel.dk> From: Jens Axboe Message-ID: <22a0156e-f74f-51c8-b7fd-9b5a375d7c81@kernel.dk> Date: Tue, 7 Sep 2021 11:18:21 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/7/21 11:14 AM, Tejun Heo wrote: > Hello, > > On Tue, Sep 07, 2021 at 10:11:21AM -0700, Roman Gushchin wrote: >> There are two polar cases: >> 1) a big number of relatively short-living allocations, which lifetime is well >> bounded (e.g. by a lifetime of a task), >> 2) a relatively small number of long-living allocations, which lifetime >> is potentially indefinite (e.g. struct mount). >> >> We can't use the same approach for both cases, otherwise we'll run into either >> performance or garbage collection problems (which also lead to performance >> problems, but delayed). > > Wouldn't a front cache which expires after some seconds catch both cases? A purely time based approach might be problematic, as you can allocate a LOT of data in a short amount of time. Heuristics probably need to be a hybrid of "time much time has passed" OR "we're over the front cache threshold in terms of deferred accounting". But yes, I don't see why we'd necessarily need different approaches for short vs long life times. -- Jens Axboe