Eric W. Biederman wrote:
Bill Davidsen <[EMAIL PROTECTED]> writes:
As long as the original parent is preserved for getppid(). There are programs
out there which communicate between the parent and child with signals, and if
the original parent dies, it undesirable to have the child getppid()
On 04/11, Bill Davidsen wrote:
>
> Oleg Nesterov wrote:
> >On 04/10, Eric W. Biederman wrote:
> >
> >>I'm trying to remember what the story is now. There is a nasty
> >>race somewhere with reparenting, a threaded parent setting SIGCHLD to
> >>SIGIGN, and non-default signals that results in an
Bill Davidsen <[EMAIL PROTECTED]> writes:
> As long as the original parent is preserved for getppid(). There are programs
> out there which communicate between the parent and child with signals, and if
> the original parent dies, it undesirable to have the child getppid() and start
> sending
Oleg Nesterov wrote:
On 04/10, Eric W. Biederman wrote:
I'm trying to remember what the story is now. There is a nasty
race somewhere with reparenting, a threaded parent setting SIGCHLD to
SIGIGN, and non-default signals that results in an zombie that no one
can wait for and reap. It
Jeff Garzik wrote:
Linus Torvalds wrote:
On Fri, 6 Apr 2007, Jeff Garzik wrote:
I would rather change the implementation under the hood to start per-CPU
threads on demand, similar to a thread-pool implementation.
Boxes with $BigNum CPUs probably won't ever use half of those threads.
The
Jeff Garzik wrote:
Linus Torvalds wrote:
On Fri, 6 Apr 2007, Jeff Garzik wrote:
I would rather change the implementation under the hood to start per-CPU
threads on demand, similar to a thread-pool implementation.
Boxes with $BigNum CPUs probably won't ever use half of those threads.
The
Oleg Nesterov wrote:
On 04/10, Eric W. Biederman wrote:
I'm trying to remember what the story is now. There is a nasty
race somewhere with reparenting, a threaded parent setting SIGCHLD to
SIGIGN, and non-default signals that results in an zombie that no one
can wait for and reap. It
Bill Davidsen [EMAIL PROTECTED] writes:
As long as the original parent is preserved for getppid(). There are programs
out there which communicate between the parent and child with signals, and if
the original parent dies, it undesirable to have the child getppid() and start
sending signals to
On 04/11, Bill Davidsen wrote:
Oleg Nesterov wrote:
On 04/10, Eric W. Biederman wrote:
I'm trying to remember what the story is now. There is a nasty
race somewhere with reparenting, a threaded parent setting SIGCHLD to
SIGIGN, and non-default signals that results in an zombie that no one
Eric W. Biederman wrote:
Bill Davidsen [EMAIL PROTECTED] writes:
As long as the original parent is preserved for getppid(). There are programs
out there which communicate between the parent and child with signals, and if
the original parent dies, it undesirable to have the child getppid() and
On Tuesday 10 April 2007, Jeff Garzik wrote:
> Thus, rather than forcing authors to make their code more complex, we
> should find another solution.
What about sth. like the "pre-forking" concept? So just have a thread creator
thread,
which checks the amount of unused threads and keeps them
On Tuesday 10 April 2007, Jeff Garzik wrote:
> That's why I feel thread creation -- cheap under Linux -- is quite
> appropriate for many of these situations.
Maybe that (thread creation) can be done at open(), socket-creation,
service request, syscall or whatever event triggers a
On Tue, 10 Apr 2007, Bill Davidsen wrote:
> Davide Libenzi wrote:
> > On Mon, 9 Apr 2007, Linus Torvalds wrote:
> >
> > > On Mon, 9 Apr 2007, Kyle Moffett wrote:
> > > > Maybe "struct posix_process" is more descriptive? "struct
> > > > process_posix"?
> > > > "Ugly POSIX process semantics data"
On Tue, Apr 10, 2007 at 03:05:56AM -0400, Jeff Garzik wrote:
> Andrew Morton wrote:
> >: root 3 0.0 0.0 0 0 ?S18:51 0:00
> >[watchdog/0]
> >
> >That's the softlockup detector. Confusingly named to look like a, err,
> >watchdog. Could probably use keventd.
>
> I
On 04/10, Eric W. Biederman wrote:
> I'm trying to remember what the story is now. There is a nasty
> race somewhere with reparenting, a threaded parent setting SIGCHLD to
> SIGIGN, and non-default signals that results in an zombie that no one
> can wait for and reap. It requires being
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> > so ... is anyone pursuing this? This would allow us to make
>> > sys_wait4() faster and more scalable: no tasklist_lock bouncing for
>> > example.
>>
>> which part?
>
> all of it :) Everything you
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > so ... is anyone pursuing this? This would allow us to make
> > sys_wait4() faster and more scalable: no tasklist_lock bouncing for
> > example.
>
> which part?
all of it :) Everything you mentioned makes sense quite a bit. The
thread
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> > on a second thought: the p->children list is needed for the whole
>> > child/parent task tree, which is needed for sys_getppid().
>>
>> Yes, something Oleg said made me realize that.
>>
>> As long
Davide Libenzi wrote:
On Mon, 9 Apr 2007, Linus Torvalds wrote:
On Mon, 9 Apr 2007, Kyle Moffett wrote:
Maybe "struct posix_process" is more descriptive? "struct process_posix"?
"Ugly POSIX process semantics data" seems simple enough to stick in a struct
name. "struct uglyposix_process"?
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > on a second thought: the p->children list is needed for the whole
> > child/parent task tree, which is needed for sys_getppid().
>
> Yes, something Oleg said made me realize that.
>
> As long as the reparent isn't to complex it isn't required
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> No! That is why I suggest (a long ago, in fact) to move ->children into
> ->signal_struct. When sub-thread forks, we set ->parent = group_leader.
> We don't need forget_original_parent() until the last thead exists. This
> also simplify do_wait().
>
>
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> Ingo Molnar <[EMAIL PROTECTED]> writes:
>>
>> > no. Two _completely separate_ lists.
>> >
>> > i.e. a to-be-reaped task will still be on the main list _too_. The
>> > main list is for all the PID
On 04/10, Ingo Molnar wrote:
>
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar <[EMAIL PROTECTED]> writes:
> >
> > > no. Two _completely separate_ lists.
> > >
> > > i.e. a to-be-reaped task will still be on the main list _too_. The
> > > main list is for all the PID
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > no. Two _completely separate_ lists.
> >
> > i.e. a to-be-reaped task will still be on the main list _too_. The
> > main list is for all the PID semantics rules. The reap-list is just
> > for
On Mon, Apr 09, 2007 at 06:48:54PM -0600, Eric W. Biederman wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > I suspect there are quite a few kernel threads which don't really need to
> > be threads at all: the code would quite happily work if it was changed to
> > use keventd, via
Ingo Molnar wrote:
* Russell King <[EMAIL PROTECTED]> wrote:
One per PC card socket to avoid the sysfs locking crappyness that
would otherwise deadlock, and to convert from the old unreadable state
machine implementation to a much more readable linearly coded
implementation.
Could probably
* Russell King <[EMAIL PROTECTED]> wrote:
> One per PC card socket to avoid the sysfs locking crappyness that
> would otherwise deadlock, and to convert from the old unreadable state
> machine implementation to a much more readable linearly coded
> implementation.
>
> Could probably be
Andrew Morton wrote:
Well that obviously would be a dumb way to use keventd. One would need
to do schedule_work(), kick off the reset then do schedule_delayed_work()
to wait (or poll) for its termination.
Far too complex. See what Russell wrote, for instance.
When you are in a kernel
On Tue, 10 Apr 2007 04:33:57 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Tue, 10 Apr 2007 03:05:56 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> >> My main
> >> worry with keventd is that we might get stuck behind an unrelated
> >> process for an undefined
Andrew Morton wrote:
On Tue, 10 Apr 2007 03:05:56 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote:
My main
worry with keventd is that we might get stuck behind an unrelated
process for an undefined length of time.
I don't think it has ever been demonstrated that keventd latency is
excessive, or
Russell King wrote:
Could probably be eliminated if we had some mechanism to spawn a helper
thread to do some task as required which didn't block other helper
threads until it completes.
kthread_run() should go that for you. Creates a new thread with
kthread_create(), and wakes it up
On Mon, Apr 09, 2007 at 07:30:56PM -0700, Andrew Morton wrote:
> : root 319 0.0 0.0 0 0 ?S18:51 0:00 [pccardd]
>
> hm.
One per PC card socket to avoid the sysfs locking crappyness that would
otherwise deadlock, and to convert from the old unreadable state machine
On Tue, 10 Apr 2007 03:05:56 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote:
> My main
> worry with keventd is that we might get stuck behind an unrelated
> process for an undefined length of time.
I don't think it has ever been demonstrated that keventd latency is
excessive, or a problem. I
Torsten Kaiser wrote:
One thread per port, not per device.
796 ?S 0:00 \_ [scsi_eh_0]
797 ?S 0:00 \_ [scsi_eh_1]
798 ?S 0:00 \_ [scsi_eh_2]
819 ?S 0:00 \_ [scsi_eh_3]
820 ?S 0:00 \_ [scsi_eh_4]
824 ?S 0:00
Linus Torvalds wrote:
On Mon, 9 Apr 2007, Andrew Morton wrote:
10 ?S< 0:00 [khelper]
That one's needed to parent the call_usermodehelper() apps. I don't think
it does anything else. We used to use keventd for this but that had some
problem whcih I forget.
I think it was one
Andrew Morton wrote:
: root 3 0.0 0.0 0 0 ?S18:51 0:00 [watchdog/0]
That's the softlockup detector. Confusingly named to look like a, err,
watchdog. Could probably use keventd.
I would think this would run into the keventd "problem", where $N
processes can
Eric W. Biederman wrote:
At 10 kernel threads per cpu there may be a little bloat but it isn't
out of control. It is mostly that we are observing the kernel as
NR_CPUS approaches infinity. 4096 isn't infinity yet but it's easily
a 1000 fold bigger then most people are used to :)
I disagree
On 4/10/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
: root 299 0.0 0.0 0 0 ?S18:51 0:00 [scsi_eh_0]
: root 300 0.0 0.0 0 0 ?S18:51 0:00 [scsi_eh_1]
: root 305 0.0 0.0 0 0 ?S18:51 0:00 [scsi_eh_2]
: root
On 4/10/07, Andrew Morton [EMAIL PROTECTED] wrote:
: root 299 0.0 0.0 0 0 ?S18:51 0:00 [scsi_eh_0]
: root 300 0.0 0.0 0 0 ?S18:51 0:00 [scsi_eh_1]
: root 305 0.0 0.0 0 0 ?S18:51 0:00 [scsi_eh_2]
: root
Eric W. Biederman wrote:
At 10 kernel threads per cpu there may be a little bloat but it isn't
out of control. It is mostly that we are observing the kernel as
NR_CPUS approaches infinity. 4096 isn't infinity yet but it's easily
a 1000 fold bigger then most people are used to :)
I disagree
Andrew Morton wrote:
: root 3 0.0 0.0 0 0 ?S18:51 0:00 [watchdog/0]
That's the softlockup detector. Confusingly named to look like a, err,
watchdog. Could probably use keventd.
I would think this would run into the keventd problem, where $N
processes can
Linus Torvalds wrote:
On Mon, 9 Apr 2007, Andrew Morton wrote:
10 ?S 0:00 [khelper]
That one's needed to parent the call_usermodehelper() apps. I don't think
it does anything else. We used to use keventd for this but that had some
problem whcih I forget.
I think it was one
Torsten Kaiser wrote:
One thread per port, not per device.
796 ?S 0:00 \_ [scsi_eh_0]
797 ?S 0:00 \_ [scsi_eh_1]
798 ?S 0:00 \_ [scsi_eh_2]
819 ?S 0:00 \_ [scsi_eh_3]
820 ?S 0:00 \_ [scsi_eh_4]
824 ?S 0:00
On Tue, 10 Apr 2007 03:05:56 -0400 Jeff Garzik [EMAIL PROTECTED] wrote:
My main
worry with keventd is that we might get stuck behind an unrelated
process for an undefined length of time.
I don't think it has ever been demonstrated that keventd latency is
excessive, or a problem. I guess we
On Mon, Apr 09, 2007 at 07:30:56PM -0700, Andrew Morton wrote:
: root 319 0.0 0.0 0 0 ?S18:51 0:00 [pccardd]
hm.
One per PC card socket to avoid the sysfs locking crappyness that would
otherwise deadlock, and to convert from the old unreadable state machine
Russell King wrote:
Could probably be eliminated if we had some mechanism to spawn a helper
thread to do some task as required which didn't block other helper
threads until it completes.
kthread_run() should go that for you. Creates a new thread with
kthread_create(), and wakes it up
Andrew Morton wrote:
On Tue, 10 Apr 2007 03:05:56 -0400 Jeff Garzik [EMAIL PROTECTED] wrote:
My main
worry with keventd is that we might get stuck behind an unrelated
process for an undefined length of time.
I don't think it has ever been demonstrated that keventd latency is
excessive, or a
On Tue, 10 Apr 2007 04:33:57 -0400 Jeff Garzik [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Tue, 10 Apr 2007 03:05:56 -0400 Jeff Garzik [EMAIL PROTECTED] wrote:
My main
worry with keventd is that we might get stuck behind an unrelated
process for an undefined length of time.
Andrew Morton wrote:
Well that obviously would be a dumb way to use keventd. One would need
to do schedule_work(), kick off the reset then do schedule_delayed_work()
to wait (or poll) for its termination.
Far too complex. See what Russell wrote, for instance.
When you are in a kernel
* Russell King [EMAIL PROTECTED] wrote:
One per PC card socket to avoid the sysfs locking crappyness that
would otherwise deadlock, and to convert from the old unreadable state
machine implementation to a much more readable linearly coded
implementation.
Could probably be eliminated if
Ingo Molnar wrote:
* Russell King [EMAIL PROTECTED] wrote:
One per PC card socket to avoid the sysfs locking crappyness that
would otherwise deadlock, and to convert from the old unreadable state
machine implementation to a much more readable linearly coded
implementation.
Could probably
On Mon, Apr 09, 2007 at 06:48:54PM -0600, Eric W. Biederman wrote:
Andrew Morton [EMAIL PROTECTED] writes:
I suspect there are quite a few kernel threads which don't really need to
be threads at all: the code would quite happily work if it was changed to
use keventd, via schedule_work()
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
no. Two _completely separate_ lists.
i.e. a to-be-reaped task will still be on the main list _too_. The
main list is for all the PID semantics rules. The reap-list is just
for wait4() processing.
On 04/10, Ingo Molnar wrote:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
no. Two _completely separate_ lists.
i.e. a to-be-reaped task will still be on the main list _too_. The
main list is for all the PID semantics rules. The reap-list
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
no. Two _completely separate_ lists.
i.e. a to-be-reaped task will still be on the main list _too_. The
main list is for all the PID semantics rules. The
Oleg Nesterov [EMAIL PROTECTED] writes:
No! That is why I suggest (a long ago, in fact) to move -children into
-signal_struct. When sub-thread forks, we set -parent = group_leader.
We don't need forget_original_parent() until the last thead exists. This
also simplify do_wait().
However,
* Eric W. Biederman [EMAIL PROTECTED] wrote:
on a second thought: the p-children list is needed for the whole
child/parent task tree, which is needed for sys_getppid().
Yes, something Oleg said made me realize that.
As long as the reparent isn't to complex it isn't required that we
Davide Libenzi wrote:
On Mon, 9 Apr 2007, Linus Torvalds wrote:
On Mon, 9 Apr 2007, Kyle Moffett wrote:
Maybe struct posix_process is more descriptive? struct process_posix?
Ugly POSIX process semantics data seems simple enough to stick in a struct
name. struct uglyposix_process?
Guys, you
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
on a second thought: the p-children list is needed for the whole
child/parent task tree, which is needed for sys_getppid().
Yes, something Oleg said made me realize that.
As long as the reparent isn't
* Eric W. Biederman [EMAIL PROTECTED] wrote:
so ... is anyone pursuing this? This would allow us to make
sys_wait4() faster and more scalable: no tasklist_lock bouncing for
example.
which part?
all of it :) Everything you mentioned makes sense quite a bit. The
thread signal handling
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
so ... is anyone pursuing this? This would allow us to make
sys_wait4() faster and more scalable: no tasklist_lock bouncing for
example.
which part?
all of it :) Everything you mentioned makes sense
On 04/10, Eric W. Biederman wrote:
I'm trying to remember what the story is now. There is a nasty
race somewhere with reparenting, a threaded parent setting SIGCHLD to
SIGIGN, and non-default signals that results in an zombie that no one
can wait for and reap. It requires being reparented
On Tue, Apr 10, 2007 at 03:05:56AM -0400, Jeff Garzik wrote:
Andrew Morton wrote:
: root 3 0.0 0.0 0 0 ?S18:51 0:00
[watchdog/0]
That's the softlockup detector. Confusingly named to look like a, err,
watchdog. Could probably use keventd.
I would think
On Tue, 10 Apr 2007, Bill Davidsen wrote:
Davide Libenzi wrote:
On Mon, 9 Apr 2007, Linus Torvalds wrote:
On Mon, 9 Apr 2007, Kyle Moffett wrote:
Maybe struct posix_process is more descriptive? struct
process_posix?
Ugly POSIX process semantics data seems simple enough to
On Tuesday 10 April 2007, Jeff Garzik wrote:
That's why I feel thread creation -- cheap under Linux -- is quite
appropriate for many of these situations.
Maybe that (thread creation) can be done at open(), socket-creation,
service request, syscall or whatever event triggers a driver/subsystem
On Tuesday 10 April 2007, Jeff Garzik wrote:
Thus, rather than forcing authors to make their code more complex, we
should find another solution.
What about sth. like the pre-forking concept? So just have a thread creator
thread,
which checks the amount of unused threads and keeps them within
On Tue, Apr 10, 2007 at 09:07:54AM +0400, Alexey Dobriyan wrote:
> On Mon, Apr 09, 2007 at 07:30:56PM -0700, Andrew Morton wrote:
> > On Mon, 9 Apr 2007 21:59:12 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
>
> [possible topic for KS2007]
>
> > > 164 ?S< 0:00 [cqueue/0]
> > >
On Mon, Apr 09, 2007 at 07:30:56PM -0700, Andrew Morton wrote:
> On Mon, 9 Apr 2007 21:59:12 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
[possible topic for KS2007]
> > 164 ?S< 0:00 [cqueue/0]
> > 165 ?S< 0:00 [cqueue/1]
> >
> > I'm not even sure wth these are.
>
> Me
On Mon, 9 Apr 2007, Andrew Morton wrote:
>
> >10 ?S< 0:00 [khelper]
>
> That one's needed to parent the call_usermodehelper() apps. I don't think
> it does anything else. We used to use keventd for this but that had some
> problem whcih I forget.
I think it was one of a long
On Mon, 9 Apr 2007 21:59:12 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 09, 2007 at 05:23:39PM -0700, Andrew Morton wrote:
>
> > I suspect there are quite a few kernel threads which don't really need to
> > be threads at all: the code would quite happily work if it was changed to
On Mon, Apr 09, 2007 at 05:23:39PM -0700, Andrew Morton wrote:
> I suspect there are quite a few kernel threads which don't really need to
> be threads at all: the code would quite happily work if it was changed to
> use keventd, via schedule_work() and friends. But kernel threads are
>
On Mon, 09 Apr 2007 18:48:54 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > I suspect there are quite a few kernel threads which don't really need to
> > be threads at all: the code would quite happily work if it was changed to
> > use
Andrew Morton <[EMAIL PROTECTED]> writes:
> I suspect there are quite a few kernel threads which don't really need to
> be threads at all: the code would quite happily work if it was changed to
> use keventd, via schedule_work() and friends. But kernel threads are
> somewhat easier to code for.
On Fri, 06 Apr 2007 18:38:40 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Robin Holt wrote:
> > We have been testing a new larger configuration and we are seeing a very
> > large scan time of init's tsk->children list. In the cases we are seeing,
> > there are numerous kernel processes created
On Mon, 9 Apr 2007, Linus Torvalds wrote:
> On Mon, 9 Apr 2007, Kyle Moffett wrote:
> >
> > Maybe "struct posix_process" is more descriptive? "struct process_posix"?
> > "Ugly POSIX process semantics data" seems simple enough to stick in a struct
> > name. "struct uglyposix_process"?
>
>
Kyle Moffett <[EMAIL PROTECTED]> writes:
> Maybe "struct posix_process" is more descriptive? "struct process_posix"?
> "Ugly POSIX process semantics data" seems simple enough to stick in a struct
> name. "struct uglyposix_process"?
Nack.
Linux internally doesn't have processes it has tasks
On Mon, 9 Apr 2007, Kyle Moffett wrote:
>
> Maybe "struct posix_process" is more descriptive? "struct process_posix"?
> "Ugly POSIX process semantics data" seems simple enough to stick in a struct
> name. "struct uglyposix_process"?
Guys, you didn't read my message.
It's *not* about
On Apr 09, 2007, at 14:09:51, Bill Davidsen wrote:
Ingo Molnar wrote:
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Fri, 6 Apr 2007, Davide Libenzi wrote:
or lets just face it and name it what it is: process_struct ;-)
That'd be fine too! Wonder if Linus would swallow a rename patch
like
Ingo Molnar wrote:
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Fri, 6 Apr 2007, Davide Libenzi wrote:
or lets just face it and name it what it is: process_struct ;-)
That'd be fine too! Wonder if Linus would swallow a rename patch like
that...
I don't really see the point. It's not even
Eric W. Biederman wrote:
Linus Torvalds <[EMAIL PROTECTED]> writes:
I'm not sure anybody would really be unhappy with pptr pointing to some
magic and special task that has pid 0 (which makes it clear to everybody
that the parent is something special), and that has SIGCHLD set to SIG_IGN
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Fri, 6 Apr 2007, Davide Libenzi wrote:
> > >
> > > or lets just face it and name it what it is: process_struct ;-)
> >
> > That'd be fine too! Wonder if Linus would swallow a rename patch like
> > that...
>
> I don't really see the point. It's
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 6 Apr 2007, Davide Libenzi wrote:
or lets just face it and name it what it is: process_struct ;-)
That'd be fine too! Wonder if Linus would swallow a rename patch like
that...
I don't really see the point. It's not even *true*.
Eric W. Biederman wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
I'm not sure anybody would really be unhappy with pptr pointing to some
magic and special task that has pid 0 (which makes it clear to everybody
that the parent is something special), and that has SIGCHLD set to SIG_IGN
(which
Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 6 Apr 2007, Davide Libenzi wrote:
or lets just face it and name it what it is: process_struct ;-)
That'd be fine too! Wonder if Linus would swallow a rename patch like
that...
I don't really see the point. It's not even
On Apr 09, 2007, at 14:09:51, Bill Davidsen wrote:
Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 6 Apr 2007, Davide Libenzi wrote:
or lets just face it and name it what it is: process_struct ;-)
That'd be fine too! Wonder if Linus would swallow a rename patch
like
On Mon, 9 Apr 2007, Kyle Moffett wrote:
Maybe struct posix_process is more descriptive? struct process_posix?
Ugly POSIX process semantics data seems simple enough to stick in a struct
name. struct uglyposix_process?
Guys, you didn't read my message.
It's *not* about process stuff.
Kyle Moffett [EMAIL PROTECTED] writes:
Maybe struct posix_process is more descriptive? struct process_posix?
Ugly POSIX process semantics data seems simple enough to stick in a struct
name. struct uglyposix_process?
Nack.
Linux internally doesn't have processes it has tasks with different
On Mon, 9 Apr 2007, Linus Torvalds wrote:
On Mon, 9 Apr 2007, Kyle Moffett wrote:
Maybe struct posix_process is more descriptive? struct process_posix?
Ugly POSIX process semantics data seems simple enough to stick in a struct
name. struct uglyposix_process?
Guys, you didn't read
On Fri, 06 Apr 2007 18:38:40 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Robin Holt wrote:
We have been testing a new larger configuration and we are seeing a very
large scan time of init's tsk-children list. In the cases we are seeing,
there are numerous kernel processes created for each
Andrew Morton [EMAIL PROTECTED] writes:
I suspect there are quite a few kernel threads which don't really need to
be threads at all: the code would quite happily work if it was changed to
use keventd, via schedule_work() and friends. But kernel threads are
somewhat easier to code for.
I
On Mon, 09 Apr 2007 18:48:54 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
Andrew Morton [EMAIL PROTECTED] writes:
I suspect there are quite a few kernel threads which don't really need to
be threads at all: the code would quite happily work if it was changed to
use keventd, via
On Mon, Apr 09, 2007 at 05:23:39PM -0700, Andrew Morton wrote:
I suspect there are quite a few kernel threads which don't really need to
be threads at all: the code would quite happily work if it was changed to
use keventd, via schedule_work() and friends. But kernel threads are
somewhat
On Mon, 9 Apr 2007 21:59:12 -0400 Dave Jones [EMAIL PROTECTED] wrote:
On Mon, Apr 09, 2007 at 05:23:39PM -0700, Andrew Morton wrote:
I suspect there are quite a few kernel threads which don't really need to
be threads at all: the code would quite happily work if it was changed to
use
On Mon, 9 Apr 2007, Andrew Morton wrote:
10 ?S 0:00 [khelper]
That one's needed to parent the call_usermodehelper() apps. I don't think
it does anything else. We used to use keventd for this but that had some
problem whcih I forget.
I think it was one of a long series
On Mon, Apr 09, 2007 at 07:30:56PM -0700, Andrew Morton wrote:
On Mon, 9 Apr 2007 21:59:12 -0400 Dave Jones [EMAIL PROTECTED] wrote:
[possible topic for KS2007]
164 ?S 0:00 [cqueue/0]
165 ?S 0:00 [cqueue/1]
I'm not even sure wth these are.
Me either.
On Tue, Apr 10, 2007 at 09:07:54AM +0400, Alexey Dobriyan wrote:
On Mon, Apr 09, 2007 at 07:30:56PM -0700, Andrew Morton wrote:
On Mon, 9 Apr 2007 21:59:12 -0400 Dave Jones [EMAIL PROTECTED] wrote:
[possible topic for KS2007]
164 ?S 0:00 [cqueue/0]
165 ?
On 04/07, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > On 04/06, Oleg Nesterov wrote:
> >>
> >> @@ -275,10 +275,7 @@ static void reparent_to_init(void)
> >>remove_parent(current);
> >>current->parent = child_reaper(current);
> >>current->real_parent =
On 04/07, Eric W. Biederman wrote:
Oleg Nesterov [EMAIL PROTECTED] writes:
On 04/06, Oleg Nesterov wrote:
@@ -275,10 +275,7 @@ static void reparent_to_init(void)
remove_parent(current);
current-parent = child_reaper(current);
current-real_parent = child_reaper(current);
-
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/06, Oleg Nesterov wrote:
>>
>> Perhaps,
>>
>> --- t/kernel/exit.c~ 2007-04-06 23:31:31.0 +0400
>> +++ t/kernel/exit.c 2007-04-06 23:31:57.0 +0400
>> @@ -275,10 +275,7 @@ static void reparent_to_init(void)
>>
On 04/06, Oleg Nesterov wrote:
>
> Perhaps,
>
> --- t/kernel/exit.c~ 2007-04-06 23:31:31.0 +0400
> +++ t/kernel/exit.c 2007-04-06 23:31:57.0 +0400
> @@ -275,10 +275,7 @@ static void reparent_to_init(void)
> remove_parent(current);
> current->parent =
1 - 100 of 198 matches
Mail list logo
