On 11/27/2012 01:27 AM, Petr Koupý wrote: >> Revision 1712 added PIO tracing, which may be contributing to this. >> [...] >> >> You may also want to try to disable the tracing code completely and see >> what happens. > > Thanks for the tip. I tried to disable PIO tracing but the CPU utilization > did not change. It got me wondering whether the issue is really caused by > revision 1712 or not. So I tried 1711 and it is happening there as well. > On the other hand, 1710 and below is not affected by this issue. I don't > see anything obvious in 1711 diff that could manifest liked that. Maybe > a syscall was introduced into some frequently executed code path which > was syscall-free previously. But that is pure guess on my part. You will > probably shed more light on it, Jakub, as you are the author of the 1711.
Hm, this seems to be related to the userspace stack size. Even though I don't understand why (yet). For me, the kernel utilization is around 26% on amd64 with 8K stacks and becomes over 40% with 1M stacks for the i8042 task. The reason I don't understand why is that there should be no real difference because the amount of allocated physical memory and mapped pages should be similar in both cases (assuming the threads and fibrils remain confined to 8K of stack anyway). I was, for a short time, suspecting as_area_destroy() could be the culprit (i.e. going through the 1M range instead of an 8K range and freeing pages from there), but then realized that since it is only inspecting used space in the area, i.e. one or two pages, it should be equally fast for 1M stacks as it is for 8K stacks. I will keep searching. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
