On Tue, Mar 04, 2014 at 07:59:29PM -0800, David Rientjes wrote:
> Now that a per-process flag is available, define it for processes that
> handle userspace oom notifications. This is an optimization to avoid
> mantaining a list of such processes attached to a memcg at any given t
Now that a per-process flag is available, define it for processes that
handle userspace oom notifications. This is an optimization to avoid
mantaining a list of such processes attached to a memcg at any given time
and iterating it at charge time.
This flag gets set whenever a process has
Hi,
this is an attempt to restart discussions regarding memcg OOM
notifications and break out conditions.
"memcg: do not hang on OOM when killed by userspace OOM access to memory
reserves" which was a first patch in the series was already merged to -mm
tree
(http://www.ozlabs.org/~
Hello, Tim.
On Thu, Dec 12, 2013 at 04:23:18PM -0800, Tim Hockin wrote:
> Just to be clear - I say this because it doesn't feel right to impose
> my craziness on others, and it sucks when we try and are met with
> "you're crazy, go away". And you have to admit that happens to
> Google. :) Punchi
On Thu, Dec 12, 2013 at 11:23 AM, Tejun Heo wrote:
> Hello, Tim.
>
> On Thu, Dec 12, 2013 at 10:42:20AM -0800, Tim Hockin wrote:
>> Yeah sorry. Replying from my phone is awkward at best. I know better :)
>
> Heh, sorry about being bitchy. :)
>
>> In my mind, the ONLY point of pulling system-OOM
Hello, Tim.
On Thu, Dec 12, 2013 at 10:42:20AM -0800, Tim Hockin wrote:
> Yeah sorry. Replying from my phone is awkward at best. I know better :)
Heh, sorry about being bitchy. :)
> In my mind, the ONLY point of pulling system-OOM handling into
> userspace is to make it easier for crazy people
On Thu, Dec 12, 2013 at 6:21 AM, Tejun Heo wrote:
> Hey, Tim.
>
> Sidenote: Please don't top-post with the whole body quoted below
> unless you're adding new cc's. Please selectively quote the original
> message's body to remind the readers of the context and reply below
> it. It's a basic lkml
On Thu 12-12-13 09:21:56, Tejun Heo wrote:
[...]
> There'd still be all the bells and whistles to configure and monitor
> system-level OOM and if there's justified need for improvements, we
> surely can and should do that;
You weren't on the CC of the original thread which has started here
https:/
Hello, Michal.
On Thu, Dec 12, 2013 at 05:32:22PM +0100, Michal Hocko wrote:
> You weren't on the CC of the original thread which has started here
> https://lkml.org/lkml/2013/11/19/191. And the original request for
> discussion was more about user defined _policies_ for the global
> OOM rather th
Hey, Tim.
Sidenote: Please don't top-post with the whole body quoted below
unless you're adding new cc's. Please selectively quote the original
message's body to remind the readers of the context and reply below
it. It's a basic lkml etiquette and one with good reasons. If you
have to top-post
The immediate problem I see with setting aside reserves "off the top"
is that we don't really know a priori how much memory the kernel
itself is going to use, which could still land us in an overcommitted
state.
In other words, if I have your 128 MB machine, and I set aside 8 MB
for OOM handling,
Yo,
On Tue, Dec 10, 2013 at 03:55:48PM -0800, David Rientjes wrote:
> > Well, the gotcha there is that you won't be able to do that with
> > system level OOM handler either unless you create a separately
> > reserved memory, which, again, can be achieved using hierarchical
> > memcg setup already.
On Tue, Dec 10, 2013 at 03:55:48PM -0800, David Rientjes wrote:
> > Okay, are you saying that userland OOM handlers will be able to dip
> > into kernel reserve memory? Maybe I'm mistaken but you realize that
> > that reserve is there to make things like task exits work under OOM
> > conditions, ri
On Tue, 10 Dec 2013, Tejun Heo wrote:
> > Indeed. The setup I'm specifically trying to attack is where the sum of
> > the limits of all non-oom handling memcgs (A/b in my model, A in yours)
> > exceed the amount of RAM. If the system has 256MB,
> >
> > /=256MB
> >
Hey, David.
On Mon, Dec 09, 2013 at 12:10:44PM -0800, David Rientjes wrote:
> Indeed. The setup I'm specifically trying to attack is where the sum of
> the limits of all non-oom handling memcgs (A/b in my model, A in yours)
> exceed the amount of RAM. If the system has 256MB,
>
>
On Mon, Dec 09, 2013 at 12:10:44PM -0800, David Rientjes wrote:
> On Fri, 6 Dec 2013, Tejun Heo wrote:
>
> > > Tejun, how are you?
> >
> > Doing pretty good. How's yourself? :)
> >
>
> Not bad, busy with holidays and all that.
>
> > > I agree that we wouldn't need such support if we are only
On Fri, 6 Dec 2013, Tejun Heo wrote:
> > Tejun, how are you?
>
> Doing pretty good. How's yourself? :)
>
Not bad, busy with holidays and all that.
> > I agree that we wouldn't need such support if we are only addressing memcg
> > oom conditions. We could do things like A/memory.limit_in_byt
On Sat, Dec 07, 2013 at 10:12:19AM -0800, Tim Hockin wrote:
> You more or less described the fundamental change - a score per memcg, with
> a recursive OOM killer which evaluates scores between siblings at the same
> level.
>
> It gets a bit complicated because we have need if wider scoring ranges
Hello Tim!
On Sat, Dec 07, 2013 at 08:38:20AM -0800, Tim Hockin wrote:
> We actually started with kernel patches all h these lines - per-memcg
> scores and all of our crazy policy requirements.
>
> It turns out that changing policies is hard.
>
> When David offered the opportunity to manage it al
Yo, David.
On Thu, Dec 05, 2013 at 03:49:57PM -0800, David Rientjes wrote:
> Tejun, how are you?
Doing pretty good. How's yourself? :)
> > Umm.. without delving into details, aren't you basically creating a
> > memory cgroup inside a memory cgroup? Doesn't sound like a
> > particularly well th
On Thu, Dec 05, 2013 at 03:49:57PM -0800, David Rientjes wrote:
> On Wed, 4 Dec 2013, Tejun Heo wrote:
>
> > Hello,
> >
>
> Tejun, how are you?
>
> > Umm.. without delving into details, aren't you basically creating a
> > memory cgroup inside a memory cgroup? Doesn't sound like a
> > particula
On Wed, 4 Dec 2013, Tejun Heo wrote:
> Hello,
>
Tejun, how are you?
> Umm.. without delving into details, aren't you basically creating a
> memory cgroup inside a memory cgroup? Doesn't sound like a
> particularly well thought-out plan to me.
>
I agree that we wouldn't need such support if w
Hello,
On Wed, Dec 04, 2013 at 05:49:04PM -0800, David Rientjes wrote:
> That's not what this series is addressing, though, and in fact it's quite
> the opposite. It acknowledges that userspace oom handlers need to
> allocate and that anything else would be too difficult to maintain
> (thereby
On Wed, 4 Dec 2013, Johannes Weiner wrote:
> > Now that a per-process flag is available, define it for processes that
> > handle userspace oom notifications. This is an optimization to avoid
> > mantaining a list of such processes attached to a memcg at any given time
>
On Tue, Dec 03, 2013 at 09:20:17PM -0800, David Rientjes wrote:
> Now that a per-process flag is available, define it for processes that
> handle userspace oom notifications. This is an optimization to avoid
> mantaining a list of such processes attached to a memcg at any given t
Now that a per-process flag is available, define it for processes that
handle userspace oom notifications. This is an optimization to avoid
mantaining a list of such processes attached to a memcg at any given time
and iterating it at charge time.
This flag gets set whenever a process has
On Tue, 30 Oct 2007 16:55:25 +0100
Jan Kara <[EMAIL PROTECTED]> wrote:
> 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 se
On Tue 30-10-07 11:23:46, Rik van Riel wrote:
> On Tue, 30 Oct 2007 15:57:20 +0100
> Jan Kara <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > > AIX contains the SIGDANGER signal to notify applications to free up some
> > > unused cached memory:
> > >
> > > http://www.ussg.iu.edu/hypermail/linu
On Tue, 30 Oct 2007 15:57:20 +0100
Jan Kara <[EMAIL PROTECTED]> 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 discuss
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.
>
Andrew Morton wrote:
> It get more complicated with NUMA memory nodes and cgroup memory
> controllers.
>
At OLS this year, users wanted user space notification of OOM
for cgroup memory controller. When a group is about to OOM,
a notification can help an external application re-adjust
memory limit
On Fri, 26 Oct 2007 14:59:01 -0700
Martin Bligh <[EMAIL PROTECTED]> wrote:
> Rik van Riel wrote:
> > On Fri, 26 Oct 2007 14:11:12 -0700
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> >> Sure, but in terms of high-level userspace interface, being able to
> >> select() on a group of priority bu
Rik van Riel wrote:
On Fri, 26 Oct 2007 14:11:12 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
Sure, but in terms of high-level userspace interface, being able to
select() on a group of priority buckets (spread across different
nodes, zones and cgroups) seems a lot more flexible than any
signa
On Fri, 26 Oct 2007 14:11:12 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Sure, but in terms of high-level userspace interface, being able to
> select() on a group of priority buckets (spread across different
> nodes, zones and cgroups) seems a lot more flexible than any
> signal-based approac
On Fri, 26 Oct 2007 14:05:47 -0700
Martin Bligh <[EMAIL PROTECTED]> wrote:
> > Martin was talking about some mad scheme wherin you'd create a bunch of
> > pseudo files (say, /proc/foo/0, /proc/foo/1, ..., /proc/foo/9) and each one
> > would become "ready" when the MM scanning priority reaches 10%,
Andrew Morton wrote:
On Thu, 18 Oct 2007 16:15:31 -0400
Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
Hi,
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 discussio
On Thu, 18 Oct 2007 16:15:31 -0400
Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
> Hi,
>
> 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 im
Samuel Tardieu wrote:
"Pavel" == Pavel Machek <[EMAIL PROTECTED]> writes:
Pavel> That works okay on a PC, but try cellphone one day.
Pavel> You want management app to close the least used
Pavel> application. You do not want _kernel_ to select "who to send
Pavel> SIGTERM to".
That's why I wou
> "Pavel" == Pavel Machek <[EMAIL PROTECTED]> writes:
Pavel> That works okay on a PC, but try cellphone one day.
Pavel> You want management app to close the least used
Pavel> application. You do not want _kernel_ to select "who to send
Pavel> SIGTERM to".
That's why I would prefer that *all*
On Thu 2007-10-18 15:10:07, Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Rene Herman wrote:
> > That first threshold sounds fine yes. To me, the second mostly sounds
> > like a job for SIGTERM though.
>
> I agree. Applications shouldn't be expected to be yet more c
Ulrich Drepper wrote:
I agree. Applications shouldn't be expected to be yet more complicated
and have different levels of low memory handling. You might want to
give a process a second shot at handling SIGDANGER but after that's it's
all about preparation for a shutdown.
I disagree. From an
On 10/19/2007 12:01 AM, Rene Herman wrote:
On 10/18/2007 11:18 PM, Rik van Riel wrote:
On Thu, 18 Oct 2007 23:06:52 +0200
Rene Herman <[EMAIL PROTECTED]> wrote:
They don't -- that's why I asked if you need both scenario's active
at the same time. SIGDANGER would just be SIGPLEASEFREEALLYOUCAN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rene Herman wrote:
> That first threshold sounds fine yes. To me, the second mostly sounds
> like a job for SIGTERM though.
I agree. Applications shouldn't be expected to be yet more complicated
and have different levels of low memory handling. You
On 10/18/2007 11:18 PM, Rik van Riel wrote:
On Thu, 18 Oct 2007 23:06:52 +0200
Rene Herman <[EMAIL PROTECTED]> wrote:
They don't -- that's why I asked if you need both scenario's active
at the same time. SIGDANGER would just be SIGPLEASEFREEALLYOUCAN with
the operator deciding through setting
On Thu, 18 Oct 2007 23:06:52 +0200
Rene Herman <[EMAIL PROTECTED]> wrote:
> They don't -- that's why I asked if you need both scenario's active
> at the same time. SIGDANGER would just be SIGPLEASEFREEALLYOUCAN with
> the operator deciding through setting the level at which point
> applications ge
On 10/18/2007 10:52 PM, Rik van Riel wrote:
On Thu, 18 Oct 2007 22:38:21 +0200
Rene Herman <[EMAIL PROTECTED]> wrote:
On 10/18/2007 10:25 PM, Marcelo Tosatti wrote:
AIX contains the SIGDANGER signal to notify applications to free up
some unused cached memory:
http://www.ussg.iu.edu/hypermail
On Thu, 18 Oct 2007 22:38:21 +0200
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 10/18/2007 10:25 PM, Marcelo Tosatti wrote:
>
> > 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.ht
On 10/18/2007 10:25 PM, Marcelo Tosatti wrote:
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 conc
Hi,
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
Hi,
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 R
50 matches
Mail list logo
