Did I miss something obvious?
And this would be a million dollar question here. I don't
think you did (although Eric (sic) constantly warns us of
dragons), but on the other hand I have very little
experience with the kernel itself.
I hope somebody comments on the fencing that is or
The target process is *already* waiting for the IO stuck inside the
kernel. It is not on a runqueue, not it is considered to be places
there.
since procwrite doesn't acquire anything other than the debug lock,
how do you know? the proc could start up again before you notice.
How?
erik quanstrom wrote:
How? If there's a stop message already written to /proc/n/ctl. Once
that is done, the process is guaranteed to be in 2 states and those
states only: continue waiting for the I/O, being actually Stopped.
Both of the don't let the scheduler take it to the runqueue.
On Nov 5, 2008, at 9:40 PM, Nathaniel W Filardo wrote:
Would this suffice?
It sounds like exactly the kind of thing I was talking about.
Did I miss something obvious?
And this would be a million dollar question here. I don't
think you did (although Eric constantly warns us of
dragons), but
On Nov 5, 2008, at 4:55 AM, erik quanstrom wrote:
I'm asking is -- dear kernel, please don't advance this process
even
if you otherwise can. All I need is a frozen state so that I can
not so easy on a multiprocessor. (unless you turn all but one
processor off.)
Hm. May be its getting
On Nov 4, 2008, at 4:34 AM, erik quanstrom wrote:
So the question remains -- what is the proper way of putting a
process
that waits for an IO into a Stopped state?
i don't think it's possible without changing the kernel.
but it's a good question, why does it work this way?
obviously one
On Thu, Nov 06, 2008 at 09:18:47PM -0800, Roman Shaposhnik wrote:
On Nov 5, 2008, at 9:40 PM, Nathaniel W Filardo wrote:
Would this suffice?
It sounds like exactly the kind of thing I was talking about.
OK. To reiterate what I said earlier, these kinds of soonstop-ed
processes may still make
On Sun, Nov 02, 2008 at 09:55:16PM -0800, Roman Shaposhnik wrote:
Guys,
when somebody tries to stop a process that is waiting for the IO the
process
doesn't get transferred to a Stopped state immediately but only when
the scheduler sees it for the first time. This leads to a process
Is there any way I can poke the target process so that it gets attention
from the scheduler an can be put in a Stopped state?
I know, I know we all don't like those guys who talk to themselves
on mailing lists replying to their own emails, but since there were
no takers here's what I
I'm glad you've asked ;-) In fact, there's a bigger context and it is
around managing processes run by cpu(1) from the terminal host. I was
planning on writing an email on that subject to this list over the
weekend but I need to amass some level of intelligence in that area
first.
For
I'm asking is -- dear kernel, please don't advance this process even
if you otherwise can. All I need is a frozen state so that I can
not so easy on a multiprocessor. (unless you turn all but one
processor off.)
- erik
On Nov 4, 2008, at 8:01 PM, erik quanstrom wrote:
I'm asking is -- dear kernel, please don't advance this process even
if you otherwise can. All I need is a frozen state so that I can
not so easy on a multiprocessor. (unless you turn all but one
processor off.)
Hm. May be its getting late,
On Nov 4, 2008, at 8:00 PM, erik quanstrom wrote:
i don't think the kernel has this level of control.
let's suppose that we have a process that gets a stop message
that's doing i/o. let's suppose that it's doing io to a particularly
cranky device with lots of neat locks that really hates
On Sun, Nov 2, 2008 at 9:55 PM, Roman Shaposhnik [EMAIL PROTECTED] wrote:
Guys,
when somebody tries to stop a process that is waiting for the IO the process
doesn't get transferred to a Stopped state immediately but only when
the scheduler sees it for the first time. This leads to a process
14 matches
Mail list logo
