linux-kernel - Re: [PATCH v2] vmpressure: implement strict mode

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:	Thu, 27 Jun 2013 18:13:53 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Anton Vorontsov <anton@...msg.org>
Cc:	Minchan Kim <minchan@...nel.org>,
	Luiz Capitulino <lcapitulino@...hat.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, mhocko@...e.cz, kmpark@...radead.org,
	hyunhee.kim@...sung.com
Subject: Re: [PATCH v2] vmpressure: implement strict mode

On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov <anton@...msg.org> wrote:

> On Thu, Jun 27, 2013 at 05:34:33PM -0700, Andrew Morton wrote:
> > > If so, userland daemon would receive lots of events which are no interest.
> > 
> > "lots"?  If vmpressure is generating events at such a high frequency that
> > this matters then it's already busted?
> 
> Current frequency is 1/(2MB). Suppose we ended up scanning the whole
> memory on a 2GB host, this will give us 1024 hits. Doesn't feel too much*
> to me... But for what it worth, I am against adding read() to the
> interface -- just because we can avoid the unnecessary switch into the
> kernel.

What was it they said about premature optimization?

I think I'd rather do nothing than add a mode hack (already!).

The information Luiz wants is already available with the existing
interface, so why not just use it until there is a real demonstrated
problem?

But all this does point at the fact that the chosen interface was not a
good one.  And it's happening so soon :( A far better interface would
be to do away with this level filtering stuff in the kernel altogether.
Register for events and you get all the events, simple.  Or require that
userspace register a separate time for each level, or whatever.

Something clean and simple which leaves the policy in userspace,
please.  Not this.

(Why didn't vmpressure use netlink, btw?  Then we'd have decent payload
delivery)
--
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/