linux-kernel - Re: OOM notifications

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]

Message-ID: <20071030155525.GF9702@duck.suse.cz>
Date:	Tue, 30 Oct 2007 16:55:25 +0100
From:	Jan Kara <jack@...e.cz>
To:	Rik van Riel <riel@...hat.com>
Cc:	Marcelo Tosatti <marcelo@...ck.org>, linux-kernel@...r.kernel.org,
	drepper@...hat.com
Subject: Re: OOM notifications

On Tue 30-10-07 11:23:46, Rik van Riel wrote:
> On Tue, 30 Oct 2007 15:57:20 +0100
> Jan Kara <jack@...e.cz> wrote:
> 
> >   Hello,
> > 
> > > AIX contains the SIGDANGER signal to notify applications to free up some
> > > unused cached memory:
> > > 
> > > http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html
> > > 
> > > There have been a few discussions on implementing such an idea on Linux,
> > > but nothing concrete has been achieved.
> > > 
> > > On the kernel side Rik suggested two notification points: "about to
> > > swap" (for desktop scenarios) and "about to OOM" (for embedded-like
> > > scenarios).
> > > 
> > > With that assumption in mind it would be necessary to either have two
> > > special devices for notification, or somehow indicate both events
> > > through the same file descriptor.
> >   Actually, wouldn't a generic netlink interface be more elegant? Then
> > we could connect it with DBUS and it would be much easier for
> > applications (Desktop) to handle such events.
> >   I agree that near-to-oom conditions are quite volatile and maybe we
> > want a technically simple (and thus more reliable) mechanism for the
> > notification but I anyway wanted to point to this possibility.
> 
> There's nothing wrong with being able to get this info via DBUS,
> but we cannot expect every database and JVM out there (big targets
> for the "reduce your memory footprint" thing on servers) to grow
> a DBUS interface.
  Hmm, that's right, but still the kernel->userspace interface could be via
netlink (which is much more flexible than signals etc.) and then in userspace
we could implement also some simple interface (UNIX socket?) for server like
apps...

									Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
-
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/