Hi!
> A process can't grab a kernel lock and then switch
> back to user mode, can it?(if it could, I can
> imagine some nasty DoS attacks...)
>
> Problem is, when we decide to schedule in a process
> or not, we know the process was last stuck in
> schedule() ... in kernel mode ;(
>
> I'd
Hi!
A process can't grab a kernel lock and then switch
back to user mode, can it?(if it could, I can
imagine some nasty DoS attacks...)
Problem is, when we decide to schedule in a process
or not, we know the process was last stuck in
schedule() ... in kernel mode ;(
I'd love to be
It dost seem to me that even when the process is not in the kernel, it
could hold other sorts of fs locks. Also, what if the process is caught in
a signal handler? Couldn't you end up being unable to kill the thing in an
overactive system?
--
This message has been brought to you by the
On Thu, 5 Oct 2000, Matti Aarnio wrote:
> On Wed, Oct 04, 2000 at 06:16:57PM -0300, Rik van Riel wrote:
[priority inversion]
> > We don't need that.
> >
> > We just need one boolean per thread ... is it holding a kernel
> > lock or not?
>
> The BKL or *any* (kernel) lock ?
>
>
On Wed, 4 Oct 2000, Rik van Riel wrote:
> On Wed, 4 Oct 2000, LA Walsh wrote:
>
> > I had another thought regarding resource scheduling -- has the
> > idea of a "weightless" process been brought up?
>
> Yes, look for "idle priority", etc..
> It also turned out to have some problems ...
>
> >
On Wed, Oct 04, 2000 at 06:16:57PM -0300, Rik van Riel wrote:
> > > ---
> > > One way would be to set a flag "I'm holding a lock" and when
> > > it releases the lock(s), deschedule it?
> >
> > There is a well-known name for this -- priority inversion.
> >
> > Implement the whole
On Thu, 5 Oct 2000, Matti Aarnio wrote:
> On Wed, Oct 04, 2000 at 12:49:43PM -0700, LA Walsh wrote:
> > > One problem here is that you might end up with a weightless
> > > process having grabbed a superblock lock, after which a
> > > normal priority CPU hog kicks in and starves the weightless
> >
On Wed, Oct 04, 2000 at 12:49:43PM -0700, LA Walsh wrote:
> > One problem here is that you might end up with a weightless
> > process having grabbed a superblock lock, after which a
> > normal priority CPU hog kicks in and starves the weightless
> > process.
> ---
> One way would be to set
On Wed, 4 Oct 2000, Nathan Paul Simons wrote:
> On Wed, Oct 04, 2000 at 04:16:22PM -0300, Rik van Riel wrote:
> > Do we have something like an in_kernel(proc) macro ???
>
> "user_mode()" in include/asm/ptrace.h? But that only checks to
> see if the regs struct you passed it are from a kernel
On Wed, Oct 04, 2000 at 04:16:22PM -0300, Rik van Riel wrote:
> Do we have something like an in_kernel(proc) macro ???
"user_mode()" in include/asm/ptrace.h? But that only checks to see if
the regs struct you passed it are from a kernel thread or not. No
checks to see if the process has any
> One problem here is that you might end up with a weightless
> process having grabbed a superblock lock, after which a
> normal priority CPU hog kicks in and starves the weightless
> process.
---
One way would be to set a flag "I'm holding a lock" and when
it releases the lock(s),
On Wed, 4 Oct 2000, LA Walsh wrote:
> I had another thought regarding resource scheduling -- has the
> idea of a "weightless" process been brought up?
Yes, look for "idle priority", etc..
It also turned out to have some problems ...
> Weightless means it doesn't count toward 'load' and the
I had another thought regarding resource scheduling -- has the idea
of a "weightless" process been brought up? Weightless means it doesn't
count toward 'load' and the class strictly has lowest priority in the
system and gets *no* CPU unless there are "idle" cycles. So even a
process niced to
I had another thought regarding resource scheduling -- has the idea
of a "weightless" process been brought up? Weightless means it doesn't
count toward 'load' and the class strictly has lowest priority in the
system and gets *no* CPU unless there are "idle" cycles. So even a
process niced to
On Wed, 4 Oct 2000, LA Walsh wrote:
I had another thought regarding resource scheduling -- has the
idea of a "weightless" process been brought up?
Yes, look for "idle priority", etc..
It also turned out to have some problems ...
Weightless means it doesn't count toward 'load' and the class
On Wed, Oct 04, 2000 at 04:16:22PM -0300, Rik van Riel wrote:
Do we have something like an in_kernel(proc) macro ???
"user_mode()" in include/asm/ptrace.h? But that only checks to see if
the regs struct you passed it are from a kernel thread or not. No
checks to see if the process has any
On Wed, 4 Oct 2000, Nathan Paul Simons wrote:
On Wed, Oct 04, 2000 at 04:16:22PM -0300, Rik van Riel wrote:
Do we have something like an in_kernel(proc) macro ???
"user_mode()" in include/asm/ptrace.h? But that only checks to
see if the regs struct you passed it are from a kernel thread
On Wed, Oct 04, 2000 at 12:49:43PM -0700, LA Walsh wrote:
One problem here is that you might end up with a weightless
process having grabbed a superblock lock, after which a
normal priority CPU hog kicks in and starves the weightless
process.
---
One way would be to set a flag
On Thu, 5 Oct 2000, Matti Aarnio wrote:
On Wed, Oct 04, 2000 at 12:49:43PM -0700, LA Walsh wrote:
One problem here is that you might end up with a weightless
process having grabbed a superblock lock, after which a
normal priority CPU hog kicks in and starves the weightless
process.
On Wed, Oct 04, 2000 at 06:16:57PM -0300, Rik van Riel wrote:
---
One way would be to set a flag "I'm holding a lock" and when
it releases the lock(s), deschedule it?
There is a well-known name for this -- priority inversion.
Implement the whole shebang of starvation
On Wed, 4 Oct 2000, Rik van Riel wrote:
On Wed, 4 Oct 2000, LA Walsh wrote:
I had another thought regarding resource scheduling -- has the
idea of a "weightless" process been brought up?
Yes, look for "idle priority", etc..
It also turned out to have some problems ...
Weightless
On Thu, 5 Oct 2000, Matti Aarnio wrote:
On Wed, Oct 04, 2000 at 06:16:57PM -0300, Rik van Riel wrote:
[priority inversion]
We don't need that.
We just need one boolean per thread ... is it holding a kernel
lock or not?
The BKL or *any* (kernel) lock ?
For my
It dost seem to me that even when the process is not in the kernel, it
could hold other sorts of fs locks. Also, what if the process is caught in
a signal handler? Couldn't you end up being unable to kill the thing in an
overactive system?
--
This message has been brought to you by the
23 matches
Mail list logo
