On Sun, 6 Oct 2013, Joel Sing wrote:
...
> I like the concept of this diff, however it is not sufficient to solve
> the multithreaded profiling problem. The reason for this is that you're
> still sending SPROCESS signals, which are delivered to the main thread
> unless another thread has diverte
On Sat, Oct 5, 2013 at 5:52 AM, Mark Kettenis wrote:
>> Date: Thu, 3 Oct 2013 18:12:59 -0700
>> From: Philip Guenther
...
>> @@ -196,11 +167,15 @@ hardclock(struct clockframe *frame)
>>*/
>> if (CLKF_USERMODE(frame) &&
>> timerisset(&pr->ps_timer[IT
On Fri, 4 Oct 2013, Philip Guenther wrote:
> On Fri, 16 Aug 2013, Ted Unangst wrote:
> > As per http://research.swtch.com/macpprof
> >
> > We deliver all prof signals to the main thread, which is unlikely to
> > result in accurate profiling info. I think the diff below fixes things.
>
> How about w
> Date: Thu, 3 Oct 2013 18:12:59 -0700
> From: Philip Guenther
>
> On Fri, 16 Aug 2013, Ted Unangst wrote:
> > As per http://research.swtch.com/macpprof
> >
> > We deliver all prof signals to the main thread, which is unlikely to
> > result in accurate profiling info. I think the diff below fixe
Setting a flag seems more straighforward than (ab)using timeouts
for this. psignal() is a rather complicated function but I don't
see any problems offhand with running it from userret().
- todd
On Thu, Oct 03, 2013 at 18:12, Philip Guenther wrote:
> How about we take an idea from FreeBSD and have hardclock() just set a
> flag on the thread and then have the thread send SIGPROF (and SIGVTALRM)
> to itself from userret(). The signal gets sent by the thread itself right
> before it checks f
On Fri, 16 Aug 2013, Ted Unangst wrote:
> As per http://research.swtch.com/macpprof
>
> We deliver all prof signals to the main thread, which is unlikely to
> result in accurate profiling info. I think the diff below fixes things.
How about we take an idea from FreeBSD and have hardclock() just s
On Fri, Aug 16, 2013 at 02:12, Ted Unangst wrote:
> As per http://research.swtch.com/macpprof
>
> We deliver all prof signals to the main thread, which is unlikely to
> result in accurate profiling info. I think the diff below fixes things.
floating this again. note that it's not the clock being
> Date: Thu, 15 Aug 2013 23:39:36 -0700
> From: Philip Guenther
>
> On Fri, 16 Aug 2013, Ted Unangst wrote:
> > As per http://research.swtch.com/macpprof
> >
> > We deliver all prof signals to the main thread, which is unlikely to
> > result in accurate profiling info. I think the diff below fix
On Fri, Aug 16, 2013 at 12:33, Mike Belopuhov wrote:
> On 16 August 2013 09:23, Ted Unangst wrote:
>> Actually, here's my concern. There's only one timeout for the process.
>> What happens when two threads are running on two CPUs? Is there a
>> guarantee that cpu0 will both set and execute the tim
On 16 August 2013 09:23, Ted Unangst wrote:
> Actually, here's my concern. There's only one timeout for the process.
> What happens when two threads are running on two CPUs? Is there a
> guarantee that cpu0 will both set and execute the timeout before cpu1
> sets it, or is there a race where cpu1
On Fri, Aug 16, 2013 at 12:23 AM, Ted Unangst wrote:
> On Thu, Aug 15, 2013 at 23:39, Philip Guenther wrote:
> > Making ITIMER_PROF per-thread like that matches neither what other OS's
> do
> > nor POSIX. jsing@ pinged about this last week and my comment then was
> > that this seems like a bug i
On Thu, Aug 15, 2013 at 23:39, Philip Guenther wrote:
> Making ITIMER_PROF per-thread like that matches neither what other OS's do
> nor POSIX. jsing@ pinged about this last week and my comment then was
> that this seems like a bug in signal delivery, not in the triggering of
> the profile timer:
On Thu, Aug 15, 2013 at 23:39, Philip Guenther wrote:
> opinions?
I knew if I made a broken diff I could trick you into fixing it right. :)
On Fri, 16 Aug 2013, Ted Unangst wrote:
> As per http://research.swtch.com/macpprof
>
> We deliver all prof signals to the main thread, which is unlikely to
> result in accurate profiling info. I think the diff below fixes things.
Making ITIMER_PROF per-thread like that matches neither what other
As per http://research.swtch.com/macpprof
We deliver all prof signals to the main thread, which is unlikely to
result in accurate profiling info. I think the diff below fixes things.
Index: kern/kern_clock.c
===
RCS file: /cvs/src/sy
16 matches
Mail list logo
