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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 C23BDC433E0 for ; Wed, 10 Mar 2021 10:41:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4D42264F51 for ; Wed, 10 Mar 2021 10:41:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D42264F51 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BC0168D0191; Wed, 10 Mar 2021 05:41:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B701C8D0148; Wed, 10 Mar 2021 05:41:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A38368D0191; Wed, 10 Mar 2021 05:41:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8A2B18D0148 for ; Wed, 10 Mar 2021 05:41:17 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3DFB3180ACEEC for ; Wed, 10 Mar 2021 10:41:17 +0000 (UTC) X-FDA: 77903622594.30.1D5B548 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf15.hostedemail.com (Postfix) with ESMTP id 209A6A0009C5 for ; Wed, 10 Mar 2021 10:41:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1615372875; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nZTPkVjV+mQdbkg1znHnpckUqBiD+p2S+HbVcCoP3kY=; b=bwZeSFYTFUaI6k5iEVR5XFMy1jPlekVWZKMv+nY/aKA6C+txpjGOWyhpx/j5aXqEg0ZQji 57JZ+A9hVmISWq5KpmmR+Li43cWJMh4Y5jD9UtZz132HBk1cpZfQ1XYn5BEOOUvyy+mzPG /hk5kqKbchb70cq4l+HcBR/14KoqXwk= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 6160DAE42; Wed, 10 Mar 2021 10:41:15 +0000 (UTC) Date: Wed, 10 Mar 2021 11:41:07 +0100 From: Michal Hocko To: Vasily Averin Cc: Shakeel Butt , Cgroups , Linux MM , Johannes Weiner , Vladimir Davydov Subject: Re: [PATCH 0/9] memcg accounting from OpenVZ Message-ID: References: <5affff71-e503-9fb9-50cb-f6d48286dd52@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 209A6A0009C5 X-Stat-Signature: zfwknfuxffuskxih3cwnkjr51kn6dt75 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615372875-220339 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: On Wed 10-03-21 13:17:19, Vasily Averin wrote: > On 3/10/21 12:12 AM, Shakeel Butt wrote: > > On Tue, Mar 9, 2021 at 12:04 AM Vasily Averin wrote: > >> > >> OpenVZ many years accounted memory of few kernel objects, > >> this helps us to prevent host memory abuse from inside memcg-limited container. > >> > > > > The text is cryptic but I am assuming you wanted to say that OpenVZ > > has remained on a kernel which was still on opt-out kmem accounting > > i.e. <4.5. Now OpenVZ wants to move to a newer kernel and thus these > > patches are needed, right? > > Something like this. > Frankly speaking I badly understand which arguments should I provide to upstream > to enable accounting for some new king of objects. > > OpenVZ used own accounting subsystem since 2001 (i.e. since v2.2.x linux kernels) > and we have accounted all required kernel objects by using our own patches. > When memcg was added to upstream Vladimir Davydov added accounting of some objects > to upstream but did not skipped another ones. > Now OpenVZ uses RHEL7-based kernels with cgroup v1 in production, and we still account > "skipped" objects by our own patches just because we accounted such objects before. > We're working on rebase to new kernels and we prefer to push our old patches to upstream. That is certainly an interesting information. But for a changelog it would be more appropriate to provide information about how much memory user can induce and whether there is any way to limit that memory by other means. How practical those other means are and which usecases will benefit from the containment. -- Michal Hocko SUSE Labs