From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD08B2566 for ; Fri, 19 Jul 2024 03:23:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721359423; cv=none; b=r64J/3qr1q3sMyhC0Zgv10lrCxO3TVqPpvMBVYF6QdJDbaS6I+Z3A3n/jVqXqA9yhxRtX2T9nVs/FrUs8lAMP91LRaQmBNghEongDAgM8SRXuC4yQWjQZMQXpgdK/gsVuc1F32c36gq8SbUAy6kyEJrExkBASQYJwd75Yfxjin4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721359423; c=relaxed/simple; bh=LzYtUaIzvRbkHQvbn06to4re3EBwEBR0G3sdQDN5Hq4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qU019SZ439SkvWO5WoMAJfll/32GUVnIUZik8B4aPAfyepHbb3IZOLnVnF1V36C4hr1aCK9+yb6xC58BkzQ/2z+glwUCuGDHc4ONTdhc3I6SMAV7M/mZUnF25vEFLFmRGH6nclK2g66gnsiRingX+pKRfYgnDXqo69Upfi1lBLg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=LTLBpHUv; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LTLBpHUv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721359419; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4g/2by4UFmJt1nLIIzaKlS2HPKjw7tCpSzx5XVWX0GE=; b=LTLBpHUvkRH3apzy6ptGf5gzKzfOHT3Uhuvci5JI1c2KpOmtg4tI5ziB3mLPq48+mlK41R vuwknZpYMpdUwfx2yNAtS8nvPv4jPVgalVP47gqrprituf6MaIgk61nwhTZQCYBH4uAS8b Bq3+ew5hB/i9DvC+LuzdO+TQYdzq8Xg= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-182-QO0slx50PEa2lPJEq-XW8w-1; Thu, 18 Jul 2024 23:23:35 -0400 X-MC-Unique: QO0slx50PEa2lPJEq-XW8w-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9E6561955F43; Fri, 19 Jul 2024 03:23:32 +0000 (UTC) Received: from [10.22.32.50] (unknown [10.22.32.50]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0C698195605A; Fri, 19 Jul 2024 03:23:28 +0000 (UTC) Message-ID: Date: Thu, 18 Jul 2024 23:23:28 -0400 Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm, memcg: cg2 memory{.swap,}.peak write handlers To: David Finkel , Johannes Weiner Cc: Tejun Heo , Michal Hocko , Muchun Song , Andrew Morton , core-services@vimeo.com, Jonathan Corbet , Roman Gushchin , Shuah Khan , Zefan Li , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Shakeel Butt References: <20240715203625.1462309-1-davidf@vimeo.com> <20240715203625.1462309-2-davidf@vimeo.com> <20240717170408.GC1321673@cmpxchg.org> Content-Language: en-US From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 On 7/18/24 17:49, David Finkel wrote: > I spent some time today attempting to implement this. > Here's a branch on github that compiles, and I think is close to what you > described, but is definitely still a WIP: > > https://github.com/torvalds/linux/compare/master...dfinkel:linux:memcg2_memory_peak_fd_session > > Since there seems to be significant agreement that this approach is better > long-term as a kernel interface, if that continues, I can factor out some of > the changes so it supports both memory.peak and memory.swap.peak, > fix the tests, and clean up any style issues tomorrow. > > Also, If there are opinions on whether the cgroup_lock is a reasonable way > of handling this synchronization, or if I should add a more appropriate spinlock > or mutex onto either the pagecounter or the memcg, I'm all ears. cgroup_lock() should only be used by the cgroup core code, though there are exceptions. You may or may not need lock protection depending on what data you want to protect and if there is any chance that concurrent race may screw thing up. If lock protection is really needed, add your own lock to protect the data. Since your critical sections seem to be pretty short, a regular spinlock will be enough. Cheers, Longman