Heiko Carstens wrote:
Changelog since v1:
1. Added a mutex to serialize directory creation/destruction for a user in
sysfs
2. Added a spinlock in the task_group structure to serialize writes to
tg->shares.
3. Removed /proc/root_user_cpu_shares.
4. Added Documentation about the group scheduler.
thanks - I have added this to the queue.
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.
Final question, how do setuid processes map into this implementation?
--
Bill Davidsen <[EMAIL PROTECTED]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
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/
