Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
Hi, Here's a trace with powerd/sleep states disabled, but I haven't set machdep.idle=spin. I'll try it with that in a sec. http://people.freebsd.org/~adrian/ath/ktr-notaskq-1.out.gz The entries are still out of whack in places, but it doesn't look like it's necessarily due to out of sync TSCs.. 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: 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 err.h
#include pthread.h
#include stdlib.h
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);
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 (120)
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
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: 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
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
On Thu, May 31, 2012 at 8:33 AM, Andriy Gapon a...@freebsd.org 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?
on 31/05/2012 15:48 Ryan Stone said the following: On Thu, May 31, 2012 at 8:33 AM, Andriy Gapon a...@freebsd.org 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:48 AM, Ryan Stone ryst...@gmail.com 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?
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?
Ryan Stone ryst...@gmail.com wrote: On Thu, May 31, 2012 at 8:33 AM, Andriy Gapon a...@freebsd.org 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: 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 j...@freebsd.org 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: 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: 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: 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: 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: 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: 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
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 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
Re: ULE/sched issues on stable/9 - why isn't preemption occuring?
On 31 May 2012 07:55, John Baldwin j...@freebsd.org 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: 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
