First and foremost, root user is handled as usual, so kernel tasks should
also be handled as usual if they always run as root...
but I've yet to find out how to check if a task is a kernel thread or not,
and skip these explicitely just to be safe.
Also, while I've coded it on a kernel thread, I'd settle perfectly to a
periodic timer, but I don't know yet ask for one... perhaps a
self-propagating workqueue entry with a delay?
> On Fri, Apr 04, 2003 at 01:27:04PM +0200, Antonio Vargas wrote:
> > If the user has many timeslices, he can give timeslices to many tasks, thus
> > getting more work done.
> > While the implementation may not be good enough, due to locking problems and
> > the use of a kernel-thread, I think the fundamental algorithm feels right.
> > William, should I take the lock on the uidhash_list when adding a task
> > to a per-user task list?
>
> Possible, though I'd favor a per-user spinlock.
So, when trying to add a task to the per-user pending tasks, I'd have
to do this:
1. spin_lock_irqsave(uidhash_lock, flags)
2. spin_lock(my_user->user_lock)
3. spin_unlock_restore(uidhash_lock, flags);
Is this any good?
Could I simply do "spin_unlock(my_user->user_lock)" at end without
taking the uidhash_lock again?
> The code looks reasonable now, modulo that race you asked about.
What do I need to lock when I want to add a task to a runqueue?
I'm doing a "spin_lock_irq(this_rq()->lock);"
As you can see, I'm not yet at speed with the locking rules... any
online references to the latest locking rules? The BKL was really
easy to understand in comparison! *grin*
Greets, Antonio.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/