(2.4 kernel)
When a process is running in the kernel, can it be pre-empted at
any time? (Unless you explicity disable preemption.) I think not,
because wouldn't it be unsafe to grab a spinlock? Or does grabbing a
spinlock disable preemption. I mean spin_lock(), not spin_lock_irqsave().
Secondly, can multiple processes be in the kernel at the same time? I
think so, that's the reason for the fine grained locks instead of the BKL.
Or do fine grained locks only serve to allow preemption.
thanks!
/fc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Frank,
[CC'ed lkml to avoid duplicate answers]
On Friday 07 November 2003 13:04, Frank Cusack wrote:
> (2.4 kernel)
>
> When a process is running in the kernel, can it be pre-empted at
> any time? (Unless you explicity disable preemption.) I think not,
> because wouldn't it be unsafe to grab a spinlock? Or does grabbing a
> spinlock disable preemption. I mean spin_lock(), not spin_lock_irqsave().
While having preemption disabled or while actually holding a spinlock,
preemption is disabled.
Disabling preemption is modifying a count, which must reach 0 again to
have preemption enabled and trigger an reschedule, if needed.
Think of it roughly as a "counter of reasons to not preempt". If there
are no reasons anymore, then we preempt.
> Secondly, can multiple processes be in the kernel at the same time? I
> think so, that's the reason for the fine grained locks instead of the BKL.
> Or do fine grained locks only serve to allow preemption.
Multiple threads can be in the kernel at the same time and even on
different CPUs. But one thread can be only on one CPU at any time.
Threads are parts of processes, so the same applies for processes, too.
Regards
Ingo Oeser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/rOlHU56oYWuOrkARAqz9AJ9bi71xchjKUJs8kysa6ePKpk13nwCeL1NB
2ti5dqrV6sQjDNbc/RqOItM=
=rb5C
-----END PGP SIGNATURE-----
On Sat, 2003-11-08 at 08:01, Ingo Oeser wrote:
> While having preemption disabled or while actually holding a spinlock,
> preemption is disabled.
>
> Disabling preemption is modifying a count, which must reach 0 again to
> have preemption enabled and trigger an reschedule, if needed.
>
> Think of it roughly as a "counter of reasons to not preempt". If there
> are no reasons anymore, then we preempt.
Hi, Ingo.
This is an accurate description of 2.6, but Frank said for 2.4.
So, Frank, this is correct for 2.6 or 2.4 with the preempt-kernel patch,
but not a stock 2.4 kernel. A stock 2.4 kernel will never preempt a
task running inside the kernel.
Robert Love
On Sat, Nov 08, 2003 at 07:23:05PM -0500, Robert Love wrote:
> On Sat, 2003-11-08 at 08:01, Ingo Oeser wrote:
>
> > While having preemption disabled or while actually holding a spinlock,
> > preemption is disabled.
> >
> > Disabling preemption is modifying a count, which must reach 0 again to
> > have preemption enabled and trigger an reschedule, if needed.
> >
> > Think of it roughly as a "counter of reasons to not preempt". If there
> > are no reasons anymore, then we preempt.
>
> Hi, Ingo.
>
> This is an accurate description of 2.6, but Frank said for 2.4.
>
> So, Frank, this is correct for 2.6 or 2.4 with the preempt-kernel patch,
> but not a stock 2.4 kernel. A stock 2.4 kernel will never preempt a
> task running inside the kernel.
Thank you for the clarification.
That leads me to 2 followup questions.
If a task in the kernel is preempted, is a membar issued? (I believe
so -- running another task means that the scheduler must have run,
which will grab and release various locks thus giving us the membars.)
When the preempted task resumes, is it guaranteed to run on the same CPU?
(I wouldn't expect so, unless the task was specifically told to do that
via hard affinity. But maybe a task preempted in the kernel is different
then a task preempted in userland.)
/fc
On Sun, 2003-11-09 at 05:04, Frank Cusack wrote:
> Thank you for the clarification.
No problem.
> That leads me to 2 followup questions.
>
> If a task in the kernel is preempted, is a membar issued? (I believe
> so -- running another task means that the scheduler must have run,
> which will grab and release various locks thus giving us the membars.)
Yes, a memory barrier is definitely issued.
> When the preempted task resumes, is it guaranteed to run on the same CPU?
> (I wouldn't expect so, unless the task was specifically told to do that
> via hard affinity. But maybe a task preempted in the kernel is different
> then a task preempted in userland.)
No. A preempted task can reschedule on any processor.
Robert Love