Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Roman Gushchin <guro@fb.com>
To:     =?iso-8859-1?Q?Michal_Koutn=FD?= <mkoutny@suse.com>
CC:     Suleiman Souhlal <suleiman@google.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Kernel Team <Kernel-team@fb.com>,
        Vladimir Davydov <vdavydov.dev@gmail.com>,
        Shakeel Butt <shakeelb@google.com>,
        Michal Hocko <mhocko@kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        Waiman Long <longman@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC 00/14] The new slab memory controller
Thread-Topic: [PATCH RFC 00/14] The new slab memory controller
Thread-Index: AQHVZDNwmo4dH7vFVEWbwj6k0KVokadGDMAAgABCQ4CAASs3gIABbVSAgABVHAA=
Date:   Thu, 3 Oct 2019 15:52:24 +0000
Message-ID: <20191003155218.GA13950@castle.DHCP.thefacebook.com>
References: <20190905214553.1643060-1-guro@fb.com>
 <20191001151202.GA6678@blackbody.suse.cz>
 <20191002020906.GB6436@castle.dhcp.thefacebook.com>
 <CABCjUKBZxJJrUzpgXafqtXOYXZbYXEh0ku8fZLpPHXWnrTw1hg@mail.gmail.com>
 <20191003104741.GB6678@blackbody.suse.cz>
In-Reply-To: <20191003104741.GB6678@blackbody.suse.cz>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:180::2898]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 589d61a2-5e8e-4321-014f-08d74819aeb8
x-ms-traffictypediagnostic: BN8PR15MB2578:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN8PR15MB2578CC716EEA98713E0DE8EDBE9F0@BN8PR15MB2578.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01792087B6
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(136003)(396003)(39860400002)(376002)(366004)(346002)(189003)(199004)(99286004)(8936002)(71190400001)(52116002)(25786009)(8676002)(71200400001)(81166006)(81156014)(76176011)(6116002)(6916009)(316002)(2906002)(33656002)(54906003)(186003)(14454004)(66446008)(6512007)(6246003)(66476007)(6486002)(9686003)(1076003)(66556008)(476003)(486006)(6436002)(46003)(446003)(11346002)(64756008)(86362001)(4326008)(14444005)(229853002)(256004)(7736002)(305945005)(478600001)(5660300002)(386003)(102836004)(66946007)(6506007);DIR:OUT;SFP:1102;SCL:1;SRVR:BN8PR15MB2578;H:BN8PR15MB2626.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1;
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: f59BgjkGZmfs4O4Gs8leQN4oC8eMToDqBa0Hv9sRhcOuKpqDNxpqwJRKnUqBjg24Gjqwq6Rgaw1NZ2giTOSFCqsRAFPCxlbgd8FEg/I7WFpm2lYPCzA3jxgT0fheFZ89Agcqf+HJk23SyuVLD6KiuhIM0mYE6YaLnnpqtgZFoP9vSRbJeUHrNQi2Mn1kG+WuTmryf0zj6G9gda1z/BJ+JQMkv63FnfQw+f4dwlctco5J0qHOcqwWb7wTTHGUJPC158eGerNtAwqOzrXYGFc5KNCrm4oru4A2/wIzrX7XeCDFZjCX4H60yMRznTB0xpdmHju6ukUuXFeFc5KB+GjDoc25YAYoY1t3hQe5oJpHCWoAyBrwJW0X8/gGturUugZyvFcOE2xDNgKKTNvKra5RACvtIB8DFb4VtwPXWKCwx14=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <D1E7D32ED58D714698C8597EF06DE8DB@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 589d61a2-5e8e-4321-014f-08d74819aeb8
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2019 15:52:24.2949
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0rwhRdnaUPPYcLLhONVyHb/MJh1vtIja6oueOJeBCo9e0E823u/YxTVoxuq9Q1dL
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB2578
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8
 definitions=2019-10-03_06:2019-10-03,2019-10-03 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 adultscore=0 bulkscore=0
 phishscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1015 spamscore=0
 malwarescore=0 mlxlogscore=999 mlxscore=0 suspectscore=0
 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-1908290000 definitions=main-1910030143
X-FB-Internal: deliver
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Oct 03, 2019 at 12:47:41PM +0200, Michal Koutn=FD wrote:
> On Wed, Oct 02, 2019 at 10:00:07PM +0900, Suleiman Souhlal <suleiman@goog=
le.com> wrote:
> > kmem.slabinfo has been absolutely invaluable for debugging, in my exper=
ience.
> > I am however not aware of any automation based on it.
> My experience is the same. However, the point is that this has been
> exposed since ages, so the safe assumption is that there may be users.

Yes, but kernel memory accounting was an opt-in feature for years,
and also it can be disabled on boot time, so displaying an empty
memory.slabinfo file doesn't break the interface.

>=20
> > Maybe it might be worth adding it to cgroup v2 and have a CONFIG
> > option to enable it?
> I don't think v2 file is necessary given the cost of obtaining the
> information. But I concur the idea of making the per-object tracking
> switchable at boot time or at least CONFIGurable.

As I said, the cost is the same and should be paid in any case,
no matter if cgroup v1 or v2 is used. A user can dynamically switch
between v1 and v2, and there is no way to obtain this information
afterwards, so we need to collect it from scratch.

Another concern I have is that it will require adding a non-trivial amount
of new code (as we don't have dynamically creating and destroying kmem_cach=
es
anymore). It's perfectly doable, but I'm not sure we need it so much
to postpone the merging of the main thing. But I'm happy to hear
any arguments why it's not true.

Thanks!