linux-kernel - Re: [discuss] memrlimit - potential applications that can use

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, 21 Aug 2008 16:43:39 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	balbir@...ux.vnet.ibm.com
Cc:	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Paul Menage <menage@...gle.com>,
	Dave Hansen <haveblue@...ibm.com>,
	Andrea Righi <righi.andrea@...il.com>,
	Hugh Dickins <hugh@...itas.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [discuss] memrlimit - potential applications that can use

On Thu, 21 Aug 2008 08:55:52 +0530
Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:

> >>> So, before we expand the use of those features to control groups by
> >>> adding a bunch of new code, let's make sure that there will be users
> >> for
> >>> it and that those users have no better way of doing it.
> >> I am all ears to better ways of doing it. Are you suggesting that overcommit was
> >> added even though we don't actually need it?
> > 
> > It serves a purpose, certainly.  We have have better ways of doing it
> > now, though.  "So, before we expand the use of those features to
> > control groups by adding a bunch of new code, let's make sure that there
> > will be users for it and that those users have no better way of doing
> > it."
> > 
> > The one concrete user that's been offered so far is postgres.  I've
> 
> No, you've been offered several, including php and apache that use memory limits.
> 
> > suggested something that I hope will be more effective than enforcing
> > overcommit.  
> 

I'm sorry I miss the point. My concern on memrlimit (for overcommiting) is that
it's not fair because an application which get -ENOMEM at mmap() is just someone
unlucky. I think it's better to trigger some notifier to application or daemon
rather than return -ENOMEM at mmap(). Notification like "Oh, it seems the VSZ
of total application exceeds the limit you set. Although you can continue your
operation, it's recommended that you should fix up the  situation".
will be good.

Thanks,
-Kame

--
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/