linux-kernel - Re: [PATCH 3/3] vmevent: Implement special low-memory attribute

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 May 2012 10:14:33 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	Anton Vorontsov <anton.vorontsov@...aro.org>
Cc:	Minchan Kim <minchan@...nel.org>,
	Leonid Moiseichuk <leonid.moiseichuk@...ia.com>,
	John Stultz <john.stultz@...aro.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linaro-kernel@...ts.linaro.org,
	patches@...aro.org, kernel-team@...roid.com
Subject: Re: [PATCH 3/3] vmevent: Implement special low-memory attribute

On Fri, May 4, 2012 at 10:38 AM, Anton Vorontsov
<anton.vorontsov@...aro.org> 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 -
> <todo-locked-file-pages>' 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/