Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755378Ab2EGHOf (ORCPT ); Mon, 7 May 2012 03:14:35 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:64583 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755048Ab2EGHOe convert rfc822-to-8bit (ORCPT ); Mon, 7 May 2012 03:14:34 -0400 MIME-Version: 1.0 In-Reply-To: <20120504073810.GA25175@lizard> References: <20120501132409.GA22894@lizard> <20120501132620.GC24226@lizard> <4FA35A85.4070804@kernel.org> <20120504073810.GA25175@lizard> Date: Mon, 7 May 2012 10:14:33 +0300 X-Google-Sender-Auth: S7I7dcU6uuS0U7QxCBF8ZKrz7R8 Message-ID: Subject: Re: [PATCH 3/3] vmevent: Implement special low-memory attribute From: Pekka Enberg To: Anton Vorontsov Cc: Minchan Kim , Leonid Moiseichuk , John Stultz , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linaro-kernel@lists.linaro.org, patches@linaro.org, kernel-team@android.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1585 Lines: 35 On Fri, May 4, 2012 at 10:38 AM, Anton Vorontsov wrote: > There are two problems. > > 1. Originally, the idea behind vmevent was that we should not expose all > ? these mm details in vmevent, because it ties ABI with Linux internal > ? memory representation; > > 2. If you have say a boolean '(A + B + C + ...) > X' attribute (which is > ? exactly what blended attributes are), you can't just set up independent > ? thresholds on A, B, C, ... and have the same effect. > > ? (What we can do, though, is... introduce arithmetic operators in > ? vmevent. :-D But then, at the end, we'll probably implement in-kernel > ? forth-like stack machine, with vmevent_config array serving as a > ? sequence of op-codes. ;-) > > If we'll give up on "1." (Pekka, ping), then we need to solve "2." > in a sane way: we'll have to add a 'NR_FILE_PAGES - NR_SHMEM - > ' attribute, and give it a name. Well, no, we can't give up on (1) completely. That'd mean that eventually we'd need to change the ABI and break userspace. The difference between exposing internal details and reasonable abstractions is by no means black and white. AFAICT, RECLAIMABLE_CACHE_PAGES is a reasonable thing to support. Can anyone come up with a reason why we couldn't do that in the future? Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/