From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751759AbdJFE27 (ORCPT ); Fri, 6 Oct 2017 00:28:59 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:59012 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751025AbdJFE26 (ORCPT ); Fri, 6 Oct 2017 00:28:58 -0400 Subject: Re: [PATCH] kvm, mm: account kvm related kmem slabs to kmemcg To: Shakeel Butt , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Vladimir Davydov , Michal Hocko , Greg Thelen References: <20171006010724.186563-1-shakeelb@google.com> Cc: Andrew Morton , linux-mm@kvack.org, x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org From: Anshuman Khandual Date: Fri, 6 Oct 2017 09:58:30 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20171006010724.186563-1-shakeelb@google.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17100604-0040-0000-0000-000003FFCE61 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17100604-0041-0000-0000-000020A13F81 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-06_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710060067 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/06/2017 06:37 AM, Shakeel Butt wrote: > The kvm slabs can consume a significant amount of system memory > and indeed in our production environment we have observed that > a lot of machines are spending significant amount of memory that > can not be left as system memory overhead. Also the allocations > from these slabs can be triggered directly by user space applications > which has access to kvm and thus a buggy application can leak > such memory. So, these caches should be accounted to kmemcg. But there may be other situations like this where user space can trigger allocation from various SLAB objects inside the kernel which are accounted as system memory. So how we draw the line which ones should be accounted for memcg. Just being curious.