confine user(s) to a core with systemd + gcgroup

[lejeczek]

hi everybody

I thought I could easily (as easily as I could do that with 
libcgroup) permanently restric a user to a specific cpu core.

I thought it would be CPUAffinity responsible for it either 
in systemd-user-sessions or(and) in systemd-logind

but it does not work,
is it possible to have user(s) sessions permanently 
restricted in this way? so his/her processes would be 
executed only on given core?
if yes then how would you do this? please shed some light

thanks
P

[Michael Cronenworth]

On 07/29/2014 09:11 AM, lejeczek wrote:
> I thought I could easily (as easily as I could do that with libcgroup)
> permanently restric a user to a specific cpu core.
>
> I thought it would be CPUAffinity responsible for it either in
> systemd-user-sessions or(and) in systemd-logind
>
> but it does not work,
> is it possible to have user(s) sessions permanently restricted in this way? so
> his/her processes would be executed only on given core?
> if yes then how would you do this? please shed some light

You should find everything you need to know on this page.

https://www.kernel.org/doc/Documentation/cgroups/cpusets.txt

The basics of it are broken down like this:

1. Create a new cpuset
2. Set cpuset settings (single cpu, etc.)
3. Start task using the new cpuset

[Bulk] Re: confine user(s) to a core with systemd + gcgroup

[lejeczek]

hi, thanks for your input, however it does not help really
linked doc? I've thumb trough it before.

let me rephrase my question - how do I put users, their 
whole session from the moment they login into a cgroup cpuset?

and I don't want to use libcgroup (as it not recommended 
anyway) but have systemd managed it.

thanks

On 29/07/14 20:38, Michael Cronenworth wrote:
> On 07/29/2014 09:11 AM, lejeczek wrote:
> > I thought I could easily (as easily as I could do that 
> > with libcgroup)
> > permanently restric a user to a specific cpu core.
> >
> > I thought it would be CPUAffinity responsible for it 
> > either in
> > systemd-user-sessions or(and) in systemd-logind
> >
> > but it does not work,
> > is it possible to have user(s) sessions permanently 
> > restricted in this way? so
> > his/her processes would be executed only on given core?
> > if yes then how would you do this? please shed some light
>
> You should find everything you need to know on this page.
>
> https://www.kernel.org/doc/Documentation/cgroups/cpusets.txt
>
> The basics of it are broken down like this:
> Create a new cpuset
> Set cpuset settings (single cpu, etc.)
> Start task using the new cpuset

[Bulk] Re: confine user(s) to a core with systemd + gcgroup

[poma]

On 30.07.2014 10:28, lejeczek wrote:
> hi, thanks for your input, however it does not help really
> linked doc? I've thumb trough it before.
>
> let me rephrase my question - how do I put users, their 
> whole session from the moment they login into a cgroup cpuset?
>
> and I don't want to use libcgroup (as it not recommended 
> anyway) but have systemd managed it.
>
> thanks

[systemd-devel] Question: who should set up the cpuset cgroup
http://lists.freedesktop.org/archives/systemd-devel/2013-September/013271.ht...

Check "systemd Development Mailing List"
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
for news related to topic, e.g. 
[systemd-devel] confine user(s) to a core with systemd + cgroup
http://lists.freedesktop.org/archives/systemd-devel/2014-July/021636.html

poma

[Bulk] Re: confine user(s) to a core with systemd + gcgroup

[Michael Cronenworth]

On 07/30/2014 03:28 AM, lejeczek wrote:
> hi, thanks for your input, however it does not help really
> linked doc? I've thumb trough it before.

Correct because systemd doesn't use cpusets.
> let me rephrase my question - how do I put users, their whole session from the
> moment they login into a cgroup cpuset?

You need to configure a login script (outside of systemd) to do use cpusets. 
Systemd uses CPU accounting and CFS switches to break down resource throttling.
> and I don't want to use libcgroup (as it not recommended anyway) but have
> systemd managed it.

If you want systemd to manage resources then you're stuck with the existing 
support, which is CPUShares. This will not have CPU limiting the way you desire.

man systemd.resource-control

The newest systemd release has a CPUQuota option that will make this work closer 
to what you want, but if you want true 1-core, 1-process resource limiting 
you're going to have to do it outside of systemd.

[Tim]

Just a curiosity question:  If you segregate a user to just one CPU
core, does that really save a system from being crippled if they max out
that core, or crash it?  I'd have thought that the rest of the system
would still be affected to some degree.  At the least, it'd have to be
completely isolated from the user's core.  And it strikes that me that a
user using the operating system isn't isolated, they interact with it.

[Bulk] Re: confine user(s) to a core with systemd + gcgroup

[lejeczek]

with new rhel 7 it's not difficult to image common setups 
where... which one is it - multi-user.target or 
network.target is the target and no gui
these naturally most often than not will be 
multicore/multisocket systems
and an admin would like to set a sort of hard ceiling above 
which users running their heavy-numbers-crunching apps could 
not go
with old libcgroup it was fairly straightforward, with 
systemd quite opposite, but I might be wrong, only started 
looking at it all
but if I'm right I would be strange redhat missed/dropped 
all these scenarios where users can be controlled/limited by 
cpusets

any other way to restrict users in/via cgroup cpu? I'm still 
thinking systemd

On 30/07/14 18:13, Tim wrote:
> Just a curiosity question:  If you segregate a user to just one CPU
> core, does that really save a system from being crippled if they max out
> that core, or crash it?  I'd have thought that the rest of the system
> would still be affected to some degree.  At the least, it'd have to be
> completely isolated from the user's core.  And it strikes that me that a
> user using the operating system isn't isolated, they interact with it.