public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chandra Seetharaman <sekharan@us.ibm.com>
To: Al Boldi <a1426z@gawab.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
	Matthew Helsley <matthltc@us.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Resource limits
Date: Tue, 27 Sep 2005 14:35:00 -0700	[thread overview]
Message-ID: <1127856900.4861.26.camel@linuxchandra> (raw)
In-Reply-To: <200509270808.21821.a1426z@gawab.com>

On Tue, 2005-09-27 at 08:08 +0300, Al Boldi wrote:
<snip>
> Consider this dilemma:
> Runaway proc/s hit the limit.
> Try to kill some and you are denied due to the resource limit.
> Use some previously running app like top, hope it hasn't been killed by some 
> OOM situation, try killing some procs and another one takes it's place 
> because of the runaway situation.
> Raise the limit, and it gets filled by the runaways.
> You are pretty much stuck.

CKRM can solve this problem nicely. You can define classes (for example,
you can define a class and it attach to a user). Limits will be applied
only to that class(user), failures will be seen only by that class(user)
and the rest of the system will be free to operate without getting into
the situation stated above.

>  and associate resources to a class 
> You may get around the problem by a user-space solution, but this will always 
> run the risks associated with user-space.
> 
> > > The issue here is a general lack of proper kernel support for resource
> > > limits.  The fork problem is just an example.
> >
> > Thats not really true.  As Mr. Helsley pointed out, CKRM is available
> 
> Matthew Helsley wrote:
> > 	Have you looked at Class-Based Kernel Resource Managment (CKRM)
> > (http://ckrm.sf.net) to see if it fits your needs? My initial thought is
> > that the CKRM numtasks controller may help limit forks in the way you
> > describe.
> 
> Thanks for the link!  CKRM is great!

Thank you!! :)
> 
> Is there a CKRM-lite version?  This would make it easier to be included into 

we are currently working on reducing the codesize and complexity of
CKRM, which will be lot thinner and less complex than what was in -mm
tree a while ago. The development is underway and you can follow the
progress of the f-series in ckrm-tech mailing list. 

> the mainline, something that would concentrate on the pressing issues, like 
> lock-out prevention, and leave all the management features as an option.
> 

You are welcome to join the mailing list and provide feedback on how the
f-series shapes up.

Thanks,

chandra 
> Thanks!
> 
> --
> Al
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------



  parent reply	other threads:[~2005-09-27 21:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-25 14:12 Resource limits Al Boldi
2005-09-26  3:36 ` Rik van Riel
2005-09-26 14:18   ` Al Boldi
2005-09-26 15:56     ` Neil Horman
2005-09-26 17:32       ` Al Boldi
2005-09-26 17:51         ` Neil Horman
2005-09-26 20:26           ` Al Boldi
2005-09-27  1:05             ` Neil Horman
2005-09-27  5:08               ` Al Boldi
2005-09-27 12:08                 ` Neil Horman
2005-09-27 13:42                   ` Al Boldi
2005-09-27 14:36                     ` Neil Horman
2005-09-27 15:50                       ` Al Boldi
2005-09-27 17:25                         ` Neil Horman
2005-09-27 21:35                 ` Chandra Seetharaman [this message]
2005-09-26 12:28 ` Neil Horman
2005-09-26 14:44 ` Roger Heflin
2005-09-26 17:11   ` Alan Cox
2005-09-26 17:32     ` Al Boldi
2005-09-26 21:21     ` Roger Heflin
2005-09-27  3:50   ` Coywolf Qi Hunt
2005-09-26 19:07 ` Matthew Helsley
  -- strict thread matches above, loose matches on Subject: below --
2002-10-24 12:13 Frank Cornelis
2002-10-24 16:46 ` Randolph Bentson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1127856900.4861.26.camel@linuxchandra \
    --to=sekharan@us.ibm.com \
    --cc=a1426z@gawab.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@us.ibm.com \
    --cc=nhorman@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox