Re: [RFC] How to handle the rules engine for cgroups

[Ulrich Drepper]

-----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-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/