All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulrich Drepper <drepper@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Rik van Riel <riel@redhat.com>, Paul Menage <menage@google.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Libcg Devel Mailing List <libcg-devel@lists.sourceforge.net>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	Peter Zijlstra <pzijlstr@redhat.com>,
	Kazunaga Ikeno <k-ikeno@ak.jp.nec.com>,
	Morton Andrew Morton <akpm@linux-foundation.org>,
	Thomas Graf <tgraf@redhat.com>
Subject: Re: [RFC] How to handle the rules engine for cgroups
Date: Thu, 10 Jul 2008 08:56:25 -0700	[thread overview]
Message-ID: <48763129.9060903@redhat.com> (raw)
In-Reply-To: <20080710154035.GA12043@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vivek Goyal wrote:
>>    it can even be hidden from the application by hooking into
>>    the exec() call
>>
> 
> This means hooking into libc. So libc will parse rules file, determine
> the right cgroup, place application there and then call exec?

As with any "solution" based on userlevel code, the problem is overhead
and interfaces.

Such a rules file would be a real file, I assume, and as such we'd have
to read it every time an exec call is made.  At least we'd have to check
using a stat() call that nothing changed.  That's always a big overhead.

Once the information is available, how is it used?  We'd have to pass
additional information to the exec syscalls.  And it has to happen so
that if the exec call fails the original process is not affected (i.e.,
premature changing isn't an option).  The method also must be
thread-safe in a limited way: executing failing exec syscalls in
multiple threads mustn't disturb the process.

There is one set of problems which I don't care about but others likely
will: what happens if some program uses the syscalls directly?  And what
happens with old libcs and old statically linked programs?  It's exactly
the kind of problem why I tell people to never linked statically but
some people don't listen.


The additional file update check is hurting performance but since I hope
what we will get an inotify-like interface that doesn't need normal file
descriptors (or any file descriptors) I think I can live with it.
Somebody would "just" have to implement, e.g., the anonfd functionality
discussed some time ago.  (Make sure to talk to Al Viro who already
mentioned to me that it'll be "fun").

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkh2MSkACgkQ2ijCOnn/RHTepgCgrlkwQMItX2QGW6Tw//lw4vH2
ItIAoJ7qyQE31jpQ2D8fBIO/yqmrwgcH
=NQMC
-----END PGP SIGNATURE-----

  reply	other threads:[~2008-07-10 15:58 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-01 19:11 [RFC] How to handle the rules engine for cgroups Vivek Goyal
2008-07-02  9:33 ` Kazunaga Ikeno
2008-07-03  1:19 ` KAMEZAWA Hiroyuki
2008-07-03 15:54   ` Vivek Goyal
2008-07-04  0:34     ` KAMEZAWA Hiroyuki
2008-07-04  3:17     ` Li Zefan
2008-07-08  9:35     ` Balbir Singh
2008-07-08 13:45       ` Vivek Goyal
2008-07-10  9:23     ` Paul Menage
2008-07-10 14:30       ` Vivek Goyal
2008-07-10 15:42         ` Dhaval Giani
2008-07-10 16:51         ` Paul Menage
2008-07-10 14:48       ` Rik van Riel
2008-07-10 15:40         ` Vivek Goyal
2008-07-10 15:56           ` Ulrich Drepper [this message]
2008-07-10 17:25             ` Rik van Riel
2008-07-10 17:39               ` Ulrich Drepper
2008-07-10 18:41                 ` Vivek Goyal
2008-07-10 22:29                   ` Ulrich Drepper
2008-07-11  0:55           ` KAMEZAWA Hiroyuki
2008-07-14 13:57             ` Vivek Goyal
2008-07-14 14:44               ` David Collier-Brown
2008-07-14 15:21                 ` Vivek Goyal
2008-07-17  7:05                   ` Kazunaga Ikeno
2008-07-17 13:47                     ` Vivek Goyal
     [not found]                       ` <20080717170717.GA3718@linux.vnet.ibm.com>
2008-07-18  8:12                         ` [Libcg-devel] " Dhaval Giani
2008-07-18 20:12                           ` Vivek Goyal
2008-08-17 10:33                   ` [RFC] [PATCH -mm] cgroup: uid-based rules to add processes efficiently in the right cgroup Andrea Righi
2008-08-18 12:35                     ` Vivek Goyal
2008-08-19 14:35                       ` righi.andrea
2008-08-18 21:05                     ` Paul Menage
2008-08-19 12:57                       ` Vivek Goyal
2008-08-26  0:54                         ` Paul Menage
2008-08-26 13:41                           ` Vivek Goyal
2008-08-26 14:35                             ` Balbir Singh
2008-08-26 15:04                               ` David Collier-Brown
2008-08-26 16:00                                 ` Vivek Goyal
2008-08-26 16:32                                   ` David Collier-Brown
2008-08-26 16:08                               ` Vivek Goyal
2008-09-04 18:25                             ` Paul Menage
2008-08-19 15:12                       ` righi.andrea
2008-08-26  0:55                         ` Paul Menage
2008-07-14 15:07               ` Re: [RFC] How to handle the rules engine for cgroups kamezawa.hiroyu
2008-07-10  9:07 ` Paul Menage
2008-07-10 14:06   ` Vivek Goyal
2008-07-10 16:41     ` Paul Menage
2008-07-10 17:19       ` Vivek Goyal
2008-07-10 17:27         ` [Libcg-devel] " Dhaval Giani
2008-07-10 14:33   ` Vivek Goyal
2008-07-10 16:46     ` Paul Menage
2008-07-10 17:18       ` [Libcg-devel] " Dhaval Giani
2008-07-10 17:30         ` Paul Menage
2008-07-10 17:44           ` Dhaval Giani
2008-07-10 15:49   ` Dhaval Giani
2008-07-18  9:52 ` KAMEZAWA Hiroyuki
2008-07-18 15:46   ` Paul Menage
2008-07-18 23:05     ` kamezawa.hiroyu
2008-07-18 16:39   ` Balbir Singh
2008-07-18 18:55     ` Vivek Goyal
2008-07-18 23:10     ` kamezawa.hiroyu

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=48763129.9060903@redhat.com \
    --to=drepper@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=k-ikeno@ak.jp.nec.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=libcg-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=pzijlstr@redhat.com \
    --cc=riel@redhat.com \
    --cc=tgraf@redhat.com \
    --cc=vgoyal@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.