From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH 00/10] cgroups: Task counter subsystem v8 Date: Mon, 1 Apr 2013 15:35:00 -0700 Message-ID: <20130401223500.GB2487@htj.dyndns.org> References: <1328067470-5980-1-git-send-email-fweisbec@gmail.com> <20130401184617.GB31435@htj.dyndns.org> <20130401202943.GC31435@htj.dyndns.org> <20130401220309.GA2487@htj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Ym4SfeqY0f5zVD1lcImi4pYCphMlCxI2hKn0jl54w9s=; b=Z5Cyy14/2RK1cYFH5cRJdD2PYob83KEPdss2uf+AUa+OhQs+3JaMVnU92trRgWSDun rIo5gKnnGKW+T34+8iMItDVt7gYcs3Ed4Xe2Zh4jvh5HPm7yQdd0dh5ykJj9Ps1tV7iO mQQDDsGZawQGbmUSKOlCPniEEH1qTD9J/WZI+kak2inwO43s/Z6Ly1TgrzjOsPRI34sV ibBTfIb1omjtBjvv+kvUM51Jk850RamX9T8Z1KMSEedT8iC3PTyW9cc9RPRaktb1D8SU cmJxHRP/0GMVm1vLKJjZV5VHENxjMYORV/xME3YqSJlxlysKFgZdcqFTF2opUtmAtl34 1URg== Content-Disposition: inline In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Tim Hockin Cc: Aditya Kali , Glauber Costa , Max Kellermann , Frederic Weisbecker , Paul Menage , Daniel J Walsh , LKML , Oleg Nesterov , Mandeep Singh Baines , Johannes Weiner , Cgroups , Andrew Morton , Containers Hey, On Mon, Apr 01, 2013 at 03:20:47PM -0700, Tim Hockin wrote: > > Ummmm.... so that's why you guys can't use kernel memory limit? :( > > Because it is completely non-obvious how to map between the two in a > way that is safe across kernel versions and not likely to blow up in > our faces. It's a hack, in other words. Now we're repeating the argument Frederic and Johannes had, so I'd suggest going back the thread and reading the discussion and if you still think using kmemcg is a bad idea, please explain why that is so. For the specific point that you just raised, the scale tilted toward thread/process count is a hacky and unreliable representation of kernel memory resource than the other way around, at least back then. If you think you can tilt it the other way, please feel free to try. Thanks. -- tejun