In ens.mailing-lists.linux-kernel, you wrote:
>
>I believe it allows the debugger to start the process to be debugged.
>
Well, the debugger simply needs to do something like
pid_t child = fork();
if (child == 0) {
ptrace(PTRACE_TRACEME,0,0,0);
Brunet <[EMAIL PROTECTED]>:
> >"Adam J. Richter" <[EMAIL PROTECTED]> said:
> >
> >>I suppose that running the child first also has a minor
> >> advantage for clone() in that it should make programs that spawn lots
> >> of threads to do little bits of work behave better on machines with a
>
>
>"Adam J. Richter" <[EMAIL PROTECTED]> said:
>
>> I suppose that running the child first also has a minor
>> advantage for clone() in that it should make programs that spawn lots
>> of threads to do little bits of work behave better on machines with a
There is another issue with this
"Adam J. Richter" [EMAIL PROTECTED] said:
I suppose that running the child first also has a minor
advantage for clone() in that it should make programs that spawn lots
of threads to do little bits of work behave better on machines with a
There is another issue with this proposition. I
Brunet [EMAIL PROTECTED]:
"Adam J. Richter" [EMAIL PROTECTED] said:
I suppose that running the child first also has a minor
advantage for clone() in that it should make programs that spawn lots
of threads to do little bits of work behave better on machines with a
There is another
In ens.mailing-lists.linux-kernel, you wrote:
I believe it allows the debugger to start the process to be debugged.
Well, the debugger simply needs to do something like
pid_t child = fork();
if (child == 0) {
ptrace(PTRACE_TRACEME,0,0,0);
>>> = Rik van Riel <[EMAIL PROTECTED]>
>> = Adam J. Richter <[EMAIL PROTECTED]>
> = Michael O'Reilly <[EMAIL PROTECTED]>
>> Rik van Riel <[EMAIL PROTECTED]> writes, regarding the idea
>> of having do_fork() give all of the parent's remaining time slice to
>> the newly created child:
>>
>>>It
On Sat, 14 Apr 2001, Linus Torvalds wrote:
> On Sat, 14 Apr 2001, Adam J. Richter wrote:
> >
> > [...]
> > >If it turns out to be beneficial to run the child first (you
> > >can measure this), why not leave everything the same as it is
> > >now but have do_fork() "switch threads" internally ?
> >
On Fri, 13 Apr 2001, Linus Torvalds wrote:
> On Sat, 14 Apr 2001, Rik van Riel wrote:
> >
> > Also, have you managed to find a real difference with this?
>
> It actually makes a noticeable difference on lmbench, so I think adam is
> 100% right.
>
> > If it turns out to be beneficial to run the
On Sat, 14 Apr 2001, Adam J. Richter wrote:
>
> [...]
> >If it turns out to be beneficial to run the child first (you
> >can measure this), why not leave everything the same as it is
> >now but have do_fork() "switch threads" internally ?
>
> That is an elegant idea.
I doubt it. It
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> Rik van Riel <[EMAIL PROTECTED]> writes, regarding the idea
> of having do_fork() give all of the parent's remaining time slice to
> the newly created child:
>
> >It could upset programs which use threads to handle
> >relatively IO poor things
Rik van Riel <[EMAIL PROTECTED]> writes, regarding the idea
of having do_fork() give all of the parent's remaining time slice to
the newly created child:
>It could upset programs which use threads to handle
>relatively IO poor things (like, waiting on disk IO in a
>thread, like glibc does to
Rik van Riel [EMAIL PROTECTED] writes, regarding the idea
of having do_fork() give all of the parent's remaining time slice to
the newly created child:
It could upset programs which use threads to handle
relatively IO poor things (like, waiting on disk IO in a
thread, like glibc does to fake
"Adam J. Richter" [EMAIL PROTECTED] writes:
Rik van Riel [EMAIL PROTECTED] writes, regarding the idea
of having do_fork() give all of the parent's remaining time slice to
the newly created child:
It could upset programs which use threads to handle
relatively IO poor things (like, waiting
On Sat, 14 Apr 2001, Adam J. Richter wrote:
[...]
If it turns out to be beneficial to run the child first (you
can measure this), why not leave everything the same as it is
now but have do_fork() "switch threads" internally ?
That is an elegant idea.
I doubt it. It sounds like one
On Sat, 14 Apr 2001, Linus Torvalds wrote:
On Sat, 14 Apr 2001, Adam J. Richter wrote:
[...]
If it turns out to be beneficial to run the child first (you
can measure this), why not leave everything the same as it is
now but have do_fork() "switch threads" internally ?
That is
= Rik van Riel [EMAIL PROTECTED]
= Adam J. Richter [EMAIL PROTECTED]
= Michael O'Reilly [EMAIL PROTECTED]
Rik van Riel [EMAIL PROTECTED] writes, regarding the idea
of having do_fork() give all of the parent's remaining time slice to
the newly created child:
It could upset programs
On Thu, 12 Apr 2001, Adam J. Richter wrote:
> I have attached the patch below. I have also adjusted the
> comment describing the code. Please let me know if this hand waving
> explanation is sufficient. I'm trying to be lazy on not do a
> measurement project to justify this relatively
On Sat, 14 Apr 2001, Rik van Riel wrote:
>
> Also, have you managed to find a real difference with this?
It actually makes a noticeable difference on lmbench, so I think adam is
100% right.
> If it turns out to be beneficial to run the child first (you
> can measure this), why not leave
Linus Torvalds <[EMAIL PROTECTED]> writes:
> spawn() is trivial to implement if you want to. I don't think it's all
> that much more interesting than vfork()+execve(), though.
spawn() (actually posix_spawn) is currently implemented in the libc.
If anybody for whatever reason thinks it is
On Fri, 13 Apr 2001, Linus Torvalds wrote:
>
>
> On 14 Apr 2001, John Fremlin wrote:
> >
> > . In fact, if you think
> > fork+exec is such a big performance hit why not go for spawn(2) and
> > have Linus and Al jump on you? ;-)
>
> spawn() is trivial to
"John Fremlin" <[EMAIL PROTECTED]> writes:
>"Adam J. Richter" <[EMAIL PROTECTED]> writes:
>> "John Fremlin" <[EMAIL PROTECTED]> writes:
>> > "Adam J. Richter" <[EMAIL PROTECTED]> writes:
>The parent is not allowed to run until the child execs, if I
>understand correctly. Read up on CLONE_VFORK.
On 14 Apr 2001, John Fremlin wrote:
>
> . In fact, if you think
> fork+exec is such a big performance hit why not go for spawn(2) and
> have Linus and Al jump on you? ;-)
spawn() is trivial to implement if you want to. I don't think it's all
that much more
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> "John Fremlin" <[EMAIL PROTECTED]> writes:
> > "Adam J. Richter" <[EMAIL PROTECTED]> writes:
> >>Guess why you're seeing this email. That's right. Linux-2.4.3's
> >> fork() does not run the child first.
>
> >[...] If an app wants to fork and
"John Fremlin" <[EMAIL PROTECTED]> writes:
> "Adam J. Richter" <[EMAIL PROTECTED]> writes:
>> Guess why you're seeing this email. That's right. Linux-2.4.3's
>> fork() does not run the child first.
>[...] If an app wants to fork and exec, it
>should use *vfork* and exec, which is a
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
[...]
> It turned out that the particular unix-like system on which
> these benchmarks were taken had a version of fork that did not run
> the child first. As it was explained to me then, most of the time,
> the child process from a fork
r" <[EMAIL PROTECTED]> on 04/12/2001 08:42:12 PM
To: Hubertus Franke/Watson/IBM@IBMUS
cc:
Subject: Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
>p->counter = (current->counter + 1) >> 1;
>current->counter = (current->counter
), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425 TL: 862-2003
"Adam J. Richter" [EMAIL PROTECTED] on 04/12/2001 08:42:12 PM
To: Hubertus Franke/Watson/IBM@IBMUS
cc:
Subject: Re: PATCH(?): linux-2.4.4-
"Adam J. Richter" [EMAIL PROTECTED] writes:
[...]
It turned out that the particular unix-like system on which
these benchmarks were taken had a version of fork that did not run
the child first. As it was explained to me then, most of the time,
the child process from a fork will do
"John Fremlin" [EMAIL PROTECTED] writes:
"Adam J. Richter" [EMAIL PROTECTED] writes:
Guess why you're seeing this email. That's right. Linux-2.4.3's
fork() does not run the child first.
[...] If an app wants to fork and exec, it
should use *vfork* and exec, which is a performance win
"Adam J. Richter" [EMAIL PROTECTED] writes:
"John Fremlin" [EMAIL PROTECTED] writes:
"Adam J. Richter" [EMAIL PROTECTED] writes:
Guess why you're seeing this email. That's right. Linux-2.4.3's
fork() does not run the child first.
[...] If an app wants to fork and exec, it
should
On 14 Apr 2001, John Fremlin wrote:
. In fact, if you think
fork+exec is such a big performance hit why not go for spawn(2) and
have Linus and Al jump on you? ;-)
spawn() is trivial to implement if you want to. I don't think it's all
that much more
"John Fremlin" [EMAIL PROTECTED] writes:
"Adam J. Richter" [EMAIL PROTECTED] writes:
"John Fremlin" [EMAIL PROTECTED] writes:
"Adam J. Richter" [EMAIL PROTECTED] writes:
The parent is not allowed to run until the child execs, if I
understand correctly. Read up on CLONE_VFORK.
I
On Fri, 13 Apr 2001, Linus Torvalds wrote:
On 14 Apr 2001, John Fremlin wrote:
. In fact, if you think
fork+exec is such a big performance hit why not go for spawn(2) and
have Linus and Al jump on you? ;-)
spawn() is trivial to implement if
Linus Torvalds [EMAIL PROTECTED] writes:
spawn() is trivial to implement if you want to. I don't think it's all
that much more interesting than vfork()+execve(), though.
spawn() (actually posix_spawn) is currently implemented in the libc.
If anybody for whatever reason thinks it is necessary
On Sat, 14 Apr 2001, Rik van Riel wrote:
Also, have you managed to find a real difference with this?
It actually makes a noticeable difference on lmbench, so I think adam is
100% right.
If it turns out to be beneficial to run the child first (you
can measure this), why not leave
On Thu, 12 Apr 2001, Adam J. Richter wrote:
I have attached the patch below. I have also adjusted the
comment describing the code. Please let me know if this hand waving
explanation is sufficient. I'm trying to be lazy on not do a
measurement project to justify this relatively
Hubertus Franke <[EMAIL PROTECTED]> writes:
>Try this ... this will guarantee that (p->counter) > (current->counter)
>and it seems not as radical
> p->counter = (current->counter + 1) >> 1;
>current->counter = (current->counter - 1) >> 1;
>if (!current->counter)
>
>> = Adam J. Richter <[EMAIL PROTECTED]>
> = Horst von Brand <[EMAIL PROTECTED]>
>> I suppose that running the child first also has a minor
>> advantage for clone() in that it should make programs that spawn lots
>> of threads to do little bits of work behave better on machines with a
>>
First the 2.4.3 tries to prefer the child.
Only does it in half of the cases though (odd counter numbers).
Your patch seems a bit radical for what you want to do.
Taking away all tokens from the parents will require that it has to wait
until the next recalculate loop.
Since (p) and (current)
"Adam J. Richter" <[EMAIL PROTECTED]> said:
[...]
> I suppose that running the child first also has a minor
> advantage for clone() in that it should make programs that spawn lots
> of threads to do little bits of work behave better on machines with a
> small number of processors, since
"Adam J. Richter" [EMAIL PROTECTED] said:
[...]
I suppose that running the child first also has a minor
advantage for clone() in that it should make programs that spawn lots
of threads to do little bits of work behave better on machines with a
small number of processors, since the
First the 2.4.3 tries to prefer the child.
Only does it in half of the cases though (odd counter numbers).
Your patch seems a bit radical for what you want to do.
Taking away all tokens from the parents will require that it has to wait
until the next recalculate loop.
Since (p) and (current)
= Adam J. Richter [EMAIL PROTECTED]
= Horst von Brand [EMAIL PROTECTED]
I suppose that running the child first also has a minor
advantage for clone() in that it should make programs that spawn lots
of threads to do little bits of work behave better on machines with a
small number of
Hubertus Franke [EMAIL PROTECTED] writes:
Try this ... this will guarantee that (p-counter) (current-counter)
and it seems not as radical
p-counter = (current-counter + 1) 1;
current-counter = (current-counter - 1) 1;
if (!current-counter)
45 matches
Mail list logo
