On Thu, Oct 04, 2007 at 12:02:01PM -0400, Bill Davidsen wrote:
> >>i'm wondering about the following: could not (yet) existing UIDs be made
> >>configurable too? I.e. if i do this in a bootup script:
> >>
> >> echo 2048 > /sys/kernel/uids/500/cpu_share
> >>
> >>this should just work too, regardless of there not being any UID 500
> >>tasks yet. Likewise, once configured, the /sys/kernel/uids/* directories
> >>(with the settings in them) should probably not go away either.
> >
> >Shouldn't that be done via uevents? E.g. UID x gets added to the sysfs
> >tree,
> >generates a uevent and a script then figures out the cpu_share and sets it.
> >That way you also don't need to keep the directories. No?
>
> That sounds complex administratively. It means that instead of setting a
> higher or lower than default once and having it persist until reboot I
> have to create a script, which *will* in some cases be left in place
> even after the need has gone.
>
> I agree with Ingo, once it's done it should be persistent.
> And as another administrative convenience I can look at that set of
> values and see what shares are being used, even when the user is not
> currently active.
Although the need seems very real, I am thinking about the implementation
aspect of this in the kernel i.e how will this be implementable?
1. The current patch proposes a sysfs based interface, where a new
directory is created for every new user created who logs into the
system. To meet the requirement Ingo suggested, it would require the
ability to create directories in sysfs in advance of (user_struct) objects
that aren't yet there - which is not possible to implement in sysfs
afaik
2. configfs seems to allow creation of directories (i.e kernel objects) from
userland. Every new directory created should translate to a
user_struct object being created in the kernel (and inserted in
uid_hash table). Would this be acceptable?
Also, IMHO, CONFIG_FAIR_USER_SCHED is there only as a toy, to test fair group
scheduling and I expect distros to support CONFIG_FAIR_CGROUP_SCHED instead
which allows "control group" (or process containers) based fair group
scheduling.
Using CONFIG_FAIR_CGROUP_SCHED it is still possible to provide user-id based
fair group scheduling, in two ways:
1. Have a daemon which listens for UID change events
(PROC_EVENT_UID) and move the task to appropriate "control
groups" and set the "control group" shares
2. Implement a "user" subsystem registered with "cgroup" core,
which automatically creates new "control groups" whenever
a new user is being added to the system. This is very similar
to "ns" subsystem (kernel/ns_cgroup.c in -mm tree).
Thus in order to provide fair user scheduling with this option,
distro needs to modify initrd to:
# mkdir /dev/usercpucontrol
# mount -t cgroup -ouser,cpu none /dev/usercpucontrol
Using a combination of these two options and a /etc configuration file
which specifies the cpu shares to be given to a user, it should be
possible for distro to give a good fair-user based scheduler.
> Final question, how do setuid processes map into this implementation?
We seem to be going by the real uid of a task (which is what tsk->user
points at) to decide its CPU bandwidth. Is that a cause of concern?
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
