Re: usertime stale at about 371k seconds
Hi, Would you please file a PR with all of your work? :-) Thanks, Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
On 31 May 2012 07:55, John Baldwin wrote: > On Wednesday, May 30, 2012 6:02:15 pm Adrian Chadd wrote: >> Hi, >> >> I've re-run the test with powerd and sleep state stuff disabled - lo >> and behold, UDP tests are now up around 240-250MBit, what I'd expect >> for this 2 stream 11n device. >> >> So why is it that I lose roughly 80MBit of throughput with powerd and >> C2/C3 enabled, when there's plenty of CPU going around? The NIC >> certainly isn't going to sleep (I've not even added that code.) > > Why do you not expect that? I would try, btw, just disabling powerd for now > and leaving C2/C3 enabled to see if that makes a difference. I expected it because I didn't know what else is going on. Thanks to your braindumping in this thread, I now have a much better appreciation for the issues here. :-) > As to my first question, with powerd enabled and an otherwise idle machine, > powerd may very well be running your CPU at some rediculously low speed (like > 100 Mhz) pretty much all the time. Do you really think you could push more > than 80 MBit with a 100 MHz CPU? This is with the power connected, so powerd seems to leave the CPU at full speed. I'll have to double-check. > Secondly, just having a lot of CPU isn't enough if you don't have it quickly. > Latency matters, too. Take a look at your C2/C3 info like so: > > dev.cpu.0.cx_supported: C1/3 C2/59 C3/93 > > IIRC, the last number is the number of microseconds the CPU takes to resume > from an interrupt. So, on this box (a Core i5), it can take 93 us after an > interrupt occurs during C3 before the CPU will get around to executing the > first instruction. It might be worse on your machine. Ok. I'll check the latency values when I'm back at home. The default bootup too is to use the ACPI idle routine, Even with powerd disabled and sleep limited to C1, I still see the TSC mismatch issues. I've modified my kernel to default to using spin at bootup. I'll see if this fixes the TSC mismatch when doing KTR traces. Thanks, Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bus device/ivars
On Thursday, May 31, 2012 12:15:48 pm Warner Losh wrote: > > On May 31, 2012, at 9:54 AM, John Baldwin wrote: > > > On Thursday, May 31, 2012 4:19:46 am Norbert Koch wrote: > >> Hello, > >> > >> I have written a bus device driver > >> which itself is a pci driver. Child devices > >> may allocate resources from my bus device. > >> > >> My bus device does the usual > >> management of resources through > >> the children's ivars. > >> > >> My question is this: > >> > >> The bus device mallocs the > >> children's ivars in bus_add_child > >> and frees the ivars in either > >> bus_detach or bus_child_detached. > >> > >> The children are added in identify > >> methods through BUS_ADD_CHILD. > >> > >> As I understand the code the bus device's > >> bus_child_detached method is called > >> in device_delete_child only if > >> the child device is already attached. > >> > >> So, there seems to be a memory leak if > >> I delete the child device in either > >> identify or probe. > >> > >> My current solution (not tested yet) is to > >> explicitly call BUS_CHILD_DETACHED > >> in the child device's code before > >> calling device_delete_child. > >> > >> Is this the correct way or is > >> there a more elegant/cleaner solution? > >> > >> I expected to find something like a > >> BUS_DELETE_CHILD method. > > > > We should perhaps have a BUS_CHILD_DELETED? I think that would do what you > > want. We could maybe add a BUS_DELETE_CHILD(), but it would be assymmetric > > to > > have device_delete_child() call BUS_DELETE_CHILD() when device_add_child() > > does not call BUS_ADD_CHILD(). (Instead, BUS_ADD_CHILD() calls > > device_add_child, which is perhaps wrong.) > > > > For now I would change your child code to call a wrapper foo_delete_child() > > function from your child drivers directly rather than calling > > device_delete_child(). foo_delete_child() can do its cleanup and then > > call > > device_delete_child(). > > We likely should have a BUS_CHILD_DELETED function that can get called for > each class in the stack when a child is deleted so you can remove the ivars. The ivars should likely stay around when the device is merely detached. Either that or we redo BUS_ADD_CHILD() such that device_add_child_ordered() invokes it (and it has a default method that does what device_add_child_ordered() does now). We could then mirror that with device_delete_child() and a BUS_DELETE_CHILD(). Here is the simpler fix (I think): Index: kern/subr_bus.c === --- kern/subr_bus.c (revision 236313) +++ kern/subr_bus.c (working copy) @@ -1873,6 +1873,8 @@ return (error); if (child->devclass) devclass_delete_device(child->devclass, child); + if (child->parent) + BUS_CHILD_DELETED(dev, child); TAILQ_REMOVE(&dev->children, child, link); TAILQ_REMOVE(&bus_data_devices, child, devlink); kobj_delete((kobj_t) child, M_BUS); Index: kern/bus_if.m === --- kern/bus_if.m (revision 236313) +++ kern/bus_if.m (working copy) @@ -160,6 +160,20 @@ }; /** + * @brief Notify a bus that a child was deleted + * + * Called at the beginning of device_delete_child() to allow the parent + * to teardown any bus-specific state for the child. + * + * @param _dev the device whose child is being deleted + * @param _child the child device which is being deleted + */ +METHOD void child_deleted { + device_t _dev; + device_t _child; +}; + +/** * @brief Notify a bus that a child was detached * * Called after the child's DEVICE_DETACH() method to allow the parent -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
announce: C Conference CFP closing June 7th
Hello- The first ever "C Conference" is happening August 28th, 2012 in San Diego, CA. The target audience are people who implement systems in C. Whether that be new languages, libraries, kernels, daemons or games. A reverse call for papers is up and closes June 7th. Submit talks you would like to give or talks you want to see given. Either way! Early bird tickets are available for $225. If you plan to attend LinuxCon/CloudOpen the following days you can get a package with C Conf and LinuxCon/CloudOpen for $520 (LinuxCon/CloudOpen are $500 alone). http://cconf.org Hope to see you there. Email me if you have any questions! Brandon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bus device/ivars
On May 31, 2012, at 9:54 AM, John Baldwin wrote: > On Thursday, May 31, 2012 4:19:46 am Norbert Koch wrote: >> Hello, >> >> I have written a bus device driver >> which itself is a pci driver. Child devices >> may allocate resources from my bus device. >> >> My bus device does the usual >> management of resources through >> the children's ivars. >> >> My question is this: >> >> The bus device mallocs the >> children's ivars in bus_add_child >> and frees the ivars in either >> bus_detach or bus_child_detached. >> >> The children are added in identify >> methods through BUS_ADD_CHILD. >> >> As I understand the code the bus device's >> bus_child_detached method is called >> in device_delete_child only if >> the child device is already attached. >> >> So, there seems to be a memory leak if >> I delete the child device in either >> identify or probe. >> >> My current solution (not tested yet) is to >> explicitly call BUS_CHILD_DETACHED >> in the child device's code before >> calling device_delete_child. >> >> Is this the correct way or is >> there a more elegant/cleaner solution? >> >> I expected to find something like a >> BUS_DELETE_CHILD method. > > We should perhaps have a BUS_CHILD_DELETED? I think that would do what you > want. We could maybe add a BUS_DELETE_CHILD(), but it would be assymmetric > to > have device_delete_child() call BUS_DELETE_CHILD() when device_add_child() > does not call BUS_ADD_CHILD(). (Instead, BUS_ADD_CHILD() calls > device_add_child, which is perhaps wrong.) > > For now I would change your child code to call a wrapper foo_delete_child() > function from your child drivers directly rather than calling > device_delete_child(). foo_delete_child() can do its cleanup and then call > device_delete_child(). We likely should have a BUS_CHILD_DELETED function that can get called for each class in the stack when a child is deleted so you can remove the ivars. The ivars should likely stay around when the device is merely detached. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bus device/ivars
On Thursday, May 31, 2012 4:19:46 am Norbert Koch wrote: > Hello, > > I have written a bus device driver > which itself is a pci driver. Child devices > may allocate resources from my bus device. > > My bus device does the usual > management of resources through > the children's ivars. > > My question is this: > > The bus device mallocs the > children's ivars in bus_add_child > and frees the ivars in either > bus_detach or bus_child_detached. > > The children are added in identify > methods through BUS_ADD_CHILD. > > As I understand the code the bus device's > bus_child_detached method is called > in device_delete_child only if > the child device is already attached. > > So, there seems to be a memory leak if > I delete the child device in either > identify or probe. > > My current solution (not tested yet) is to > explicitly call BUS_CHILD_DETACHED > in the child device's code before > calling device_delete_child. > > Is this the correct way or is > there a more elegant/cleaner solution? > > I expected to find something like a > BUS_DELETE_CHILD method. We should perhaps have a BUS_CHILD_DELETED? I think that would do what you want. We could maybe add a BUS_DELETE_CHILD(), but it would be assymmetric to have device_delete_child() call BUS_DELETE_CHILD() when device_add_child() does not call BUS_ADD_CHILD(). (Instead, BUS_ADD_CHILD() calls device_add_child, which is perhaps wrong.) For now I would change your child code to call a wrapper foo_delete_child() function from your child drivers directly rather than calling device_delete_child(). foo_delete_child() can do its cleanup and then call device_delete_child(). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thursday, May 31, 2012 11:11:11 am Mark Felder wrote: > So when this hang happens, there never is a real panic. It just sits in a > state which I describe as like being in a deadlock. How would I go about > getting a crashdump if it never panics? Is it possible to do the dump over > a network or something because I don't believe it can write through the > controller at all. You can break into ddb and run 'call doadump'. It should use polled IO, so there is a slight chance of it working. > Also, thank you for the KTR_SCHED tip. This is the type of info I was > looking for. Unfortunately I've only ever seen this crash once on a kernel > with debugging enabled. The machine which is currently prepared to do this > work used to crash a few times a week and now it has 70 days uptime... > however, it is an example of a machine with mpt0 and em0 sharing an IRQ so > I might be able to trigger it using Dane's method. > > $ vmstat -i > interrupt total rate > irq1: atkbd0 392 0 > irq6: fdc0 9 0 > irq14: ata0 34 0 > irq18: em0 mpt0 1189748491218 > cpu0: timer 2174263198400 > Total 3364012124619 > > > I'm doing my best to get you guys the info you need, but this is one heck > of a Heisenbug... Thanks. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
On 05/31/12 01:02, Adrian Chadd wrote: I've re-run the test with powerd and sleep state stuff disabled - lo and behold, UDP tests are now up around 240-250MBit, what I'd expect for this 2 stream 11n device. So why is it that I lose roughly 80MBit of throughput with powerd and C2/C3 enabled, when there's plenty of CPU going around? The NIC certainly isn't going to sleep (I've not even added that code.) I've seen penalties from both of them myself on latency-sensitive single-threaded disk benchmark: 17K IOPS instead of 30K IOPS without. Problem with powerd was that CPU load during the test was below powerd idle threshold and it decided to drop frequency, that proportionally increased I/O handling latency. powerd can't know that while average CPU load is now, the request handling latency is critical for the test. About C-states, I've noticed on my tests on Core2Duo system that while ACPI reports equal exit latency for C1 and C2 states of 1us there, they are not really equal -- C2 exit is measurably slower. On newer generations of systems (Core i) I've never seen C2 latency reported as 1us, but instead it has much higher values. Having real big value there system should automatically avoid entering those states under the high interrupt rates to not get penalties. But that is all about latency-sensitive test. I am surprised to see such results for the network benchmarks. Handling packets in bursts should hide that latency. Unless you are loosing packets because of some overflows during these delays. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
On Wednesday, May 30, 2012 6:02:15 pm Adrian Chadd wrote: > Hi, > > I've re-run the test with powerd and sleep state stuff disabled - lo > and behold, UDP tests are now up around 240-250MBit, what I'd expect > for this 2 stream 11n device. > > So why is it that I lose roughly 80MBit of throughput with powerd and > C2/C3 enabled, when there's plenty of CPU going around? The NIC > certainly isn't going to sleep (I've not even added that code.) Why do you not expect that? I would try, btw, just disabling powerd for now and leaving C2/C3 enabled to see if that makes a difference. As to my first question, with powerd enabled and an otherwise idle machine, powerd may very well be running your CPU at some rediculously low speed (like 100 Mhz) pretty much all the time. Do you really think you could push more than 80 MBit with a 100 MHz CPU? Secondly, just having a lot of CPU isn't enough if you don't have it quickly. Latency matters, too. Take a look at your C2/C3 info like so: dev.cpu.0.cx_supported: C1/3 C2/59 C3/93 IIRC, the last number is the number of microseconds the CPU takes to resume from an interrupt. So, on this box (a Core i5), it can take 93 us after an interrupt occurs during C3 before the CPU will get around to executing the first instruction. It might be worse on your machine. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
So when this hang happens, there never is a real panic. It just sits in a state which I describe as like being in a deadlock. How would I go about getting a crashdump if it never panics? Is it possible to do the dump over a network or something because I don't believe it can write through the controller at all. Also, thank you for the KTR_SCHED tip. This is the type of info I was looking for. Unfortunately I've only ever seen this crash once on a kernel with debugging enabled. The machine which is currently prepared to do this work used to crash a few times a week and now it has 70 days uptime... however, it is an example of a machine with mpt0 and em0 sharing an IRQ so I might be able to trigger it using Dane's method. $ vmstat -i interrupt total rate irq1: atkbd0 392 0 irq6: fdc0 9 0 irq14: ata0 34 0 irq18: em0 mpt0 1189748491218 cpu0: timer 2174263198400 Total 3364012124619 I'm doing my best to get you guys the info you need, but this is one heck of a Heisenbug... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Wednesday, May 30, 2012 3:56:02 pm Mark Felder wrote: > On Wed, 30 May 2012 12:17:07 -0500, John Baldwin wrote: > > > > > Humm, can you test it with 2 CPUs? > > > > We primarily only run with 1 CPU. We have seen it crash on multiple CPU > VMs. Also, Dane Foster appeared to have been using multiple CPUs in his > video transcoding VMs. > > Unfortunately I can't give you more information at the moment. I'm working > with Dane to compile easy to follow steps that recreate this failure. I > have not been successful in getting this to crash on demand in my > environment, but Dane has so we're trying to recreate his. Ok. It would be really helpful if we could get a crashdump, though I realize that may not be doable. Otherwise, full DDB ps output from a hang would be a good start. Primarily I would want to see what the system is doing and why it isn't running the threads on the run queue. It might also be useful to add KTR_SCHED tracing so we can get the output of that via 'show ktr' from DDB when it hangs. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
Ryan Stone wrote: > On Thu, May 31, 2012 at 8:33 AM, Andriy Gapon wrote: > > In this vein it might make sense to enable KTR and KTR_SCHED in GENERIC. > > KTR_SCHED comes with a performance hit. Besides, with the DTrace > sched provider that I committed this month (and MFC'ed yesterday) you > can collect schedgraph data with a D script. Unfortunately DTrace's timestamp itself doesn't always work reliably on FreeBSD, and schedgraph.d depends on it. On my system DTrace's timestamp seems to work with kern.timecounter.hardware=HPET and dev.cpu.0.cx_lowest=C2 (or C1) but seems to tick much too slow with dev.cpu.0.cx_lowest=C3: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026710.html Fabian signature.asc Description: PGP signature
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
Hi, That's cool and one of the things I'm using this to investigate. However, I'm still seeing weird TSC behaviour, which I'd like to finish trying to root cause before moving onto bigger and weirder things. I'm not sure how feasible it'd be to "make" KTR work with power saving modes enabled on these older model CPUs. John/Doug has pointed out later CPUs have P-state invariant TSC counters, which would render all of this moot. Great, but that's not the test hardware I have. :-) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
On Thu, May 31, 2012 at 8:48 AM, Ryan Stone wrote: > KTR_SCHED comes with a performance hit. Besides, with the DTrace > sched provider that I committed this month (and MFC'ed yesterday) you > can collect schedgraph data with a D script. I suppose it would have been helpful to provide a link to the script: http://people.freebsd.org/~rstone/dtrace/schedgraph.d Post-process it with this before feeding it to schedgraph.py: http://people.freebsd.org/~rstone/dtrace/make_ktr ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
on 31/05/2012 15:48 Ryan Stone said the following: > On Thu, May 31, 2012 at 8:33 AM, Andriy Gapon wrote: >> In this vein it might make sense to enable KTR and KTR_SCHED in GENERIC. > > KTR_SCHED comes with a performance hit. Yep, I realize that. But I hope that it is not too huge for typical users of GENERIC. BTW, by "enable" I actually meant to compile it in, not really activate it. > Besides, with the DTrace > sched provider that I committed this month (and MFC'ed yesterday) you > can collect schedgraph data with a D script. Thank you for the reminder. I am still to try it out. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
On Thu, May 31, 2012 at 8:33 AM, Andriy Gapon wrote: > In this vein it might make sense to enable KTR and KTR_SCHED in GENERIC. KTR_SCHED comes with a performance hit. Besides, with the DTrace sched provider that I committed this month (and MFC'ed yesterday) you can collect schedgraph data with a D script. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
Sorry to hijack this thread, but just recently I've stumbled upon this Linux tool: http://lwn.net/Articles/353295/ perf sched latency seems to be particularly convenient and useful. The idea to track time between a point when a thread is waken up and a point when the thread actually run was quite good. I am sure that something like this could be scripted on top of ktr(4) using the trace points in the schedulers code. schedgraph is very cool, but it seems to lack some auto-analysis capabilities which would highlight the most interesting places. In this vein it might make sense to enable KTR and KTR_SCHED in GENERIC. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
bus device/ivars
Hello, I have written a bus device driver which itself is a pci driver. Child devices may allocate resources from my bus device. My bus device does the usual management of resources through the children's ivars. My question is this: The bus device mallocs the children's ivars in bus_add_child and frees the ivars in either bus_detach or bus_child_detached. The children are added in identify methods through BUS_ADD_CHILD. As I understand the code the bus device's bus_child_detached method is called in device_delete_child only if the child device is already attached. So, there seems to be a memory leak if I delete the child device in either identify or probe. My current solution (not tested yet) is to explicitly call BUS_CHILD_DETACHED in the child device's code before calling device_delete_child. Is this the correct way or is there a more elegant/cleaner solution? I expected to find something like a BUS_DELETE_CHILD method. Thank you for any advice, Norbert Koch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: usertime stale at about 371k seconds
On 5/30/12 11:27 PM, Andrey Zonov wrote: Hi, I have long running process for which `ps -o usertime -p $pid' shows always the same time - 6190:07.65, `ps -o cputime -p $pid' for the same process continue to grow and now it's 21538:53.61. It looks like overflow in resource usage code or something. I reproduced that problem with attached program. I ran it with 23 threads on machine with 24 CPUs and after night I see this: $ ps -o usertime,time -p 24134 && sleep 60 && ps -o usertime,time -p 24134 USERTIMETIME 6351:24.74 14977:35.19 USERTIMETIME 6351:24.74 15000:34.53 Per thread user-time counts correct: $ ps -H -o usertime,time -p 24134 USERTIME TIME 0:00.00 0:00.00 652:35.84 652:38.59 652:34.75 652:37.97 652:50.46 652:51.97 652:38.93 652:43.08 652:39.73 652:43.36 652:44.09 652:47.36 652:56.49 652:57.94 652:51.84 652:54.41 652:37.48 652:41.57 652:36.61 652:40.90 652:39.41 652:42.52 653:03.72 653:06.72 652:49.96 652:53.25 652:45.92 652:49.03 652:40.33 652:42.05 652:46.53 652:49.31 652:44.77 652:47.33 653:00.54 653:02.24 652:33.31 652:36.13 652:51.03 652:52.91 652:50.73 652:52.71 652:41.32 652:44.64 652:59.86 653:03.25 (kgdb) p $my->p_rux $14 = {rux_runtime = 2171421985692826, rux_uticks = 114886093, rux_sticks = 8353, rux_iticks = 0, rux_uu = 381084736784, rux_su = 65773652, rux_tu = 904571706136} (kgdb) p $my->p_rux $15 = {rux_runtime = 2191831516209186, rux_uticks = 115966087, rux_sticks = 8444, rux_iticks = 0, rux_uu = 381084736784, rux_su = 66458587, rux_tu = 913099969825} As you can see rux_uu stale, but rux_uticks still ticks. I think the problem is in calcru1(). This expression uu = (tu * ut) / tt overflows. I applied the following patch: Index: /usr/src/sys/kern/kern_resource.c === --- /usr/src/sys/kern/kern_resource.c (revision 235394) +++ /usr/src/sys/kern/kern_resource.c (working copy) @@ -885,7 +885,7 @@ calcru1(struct proc *p, struct rusage_ext *ruxp, s struct timeval *sp) { /* {user, system, interrupt, total} {ticks, usec}: */ - uint64_t ut, uu, st, su, it, tt, tu; + uint64_t ut, uu, st, su, it, tt, tu, tmp; ut = ruxp->rux_uticks; st = ruxp->rux_sticks; @@ -909,10 +909,20 @@ calcru1(struct proc *p, struct rusage_ext *ruxp, s * The normal case, time increased. * Enforce monotonicity of bucketed numbers. */ - uu = (tu * ut) / tt; + if (ut == 0) + uu = 0; + else { + tmp = tt / ut; + uu = tmp ? tu / tmp : 0; + } if (uu < ruxp->rux_uu) uu = ruxp->rux_uu; and now ran test again. -- Andrey Zonov /* * Andrey Zonov (c) 2012 */ #include #include #include void *func(void *arg); int main(int argc, char **argv) { int i; int threads; int *tid; pthread_t *tds; if (argc != 2) errx(1, "usage: usertime "); threads = atoi(argv[1]); tid = malloc(sizeof(int) * threads); tds = malloc(sizeof(pthread_t) * threads); for (i = 0; i < threads; i++) { tid[i] = i; if (pthread_create(&tds[i], NULL, func, &tid[i]) != 0) err(1, "pthread_create(%d)", i); } for (i = 0; i < threads; i++) if (pthread_join(tds[i], NULL) != 0) err(1, "pthread_join(%d)", i); exit(0); } void * func(void *arg __unused) { int i; #define MAX (1<<20) for (i = 0; i < MAX; i++) { if ((i % (MAX - 1)) == 0) { i = 0; /*usleep(1);*/ } } pthread_exit(NULL); } ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"