Re: [TEST/REVIEW] CPU accounting patches

On Tuesday 24 January 2006 16:10, Poul-Henning Kamp wrote:
> Here is a new version of my cpu accounting change patch.
>
> http://phk.freebsd.dk/patch/cpu_acct_1.patch
>
> This patch is supposedly harmless (or at least mostly harmless)
> and I'd appreciate it getting a solid trashing.

The XXX in calcru1() you can remove. The rux you are adding the current time
to is a local rusage_ext on the stack. However, your changes probably make
it bogus in that the current code assumes it can subtract the start time of
another CPU (for a thread running on another CPU) from the current time on
this CPU to get the amount of time the other thread has been running on the
other CPU since it last updated p->p_rux.rux_runtime. However, with the CPUs
having disparate timings this would break as curthread's CPU's notion of now
will be unrelated to the other thread's CPU's notion of now.

Other than that this patch looks fine to me. FYI, Alpha also has a per-cpu
counter (RPCC) that is used for the timecounter on UP Alphas.

--
John Baldwin <jhb@xxxxxxxxxxx> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [TEST/REVIEW] CPU accounting patches
    ... > This patch is supposedly harmless ... another CPU from the current time on ... Other than that this patch looks fine to me. ... Alpha also has a per-cpu ...
    (freebsd-current)
  • Re: RT patch acceptance (scheduler)
    ... > lock up the CPU in IRQ mode for human-perceptible time, ... For non-DMA IDE access data copies are CPU driven ... which can create tons of latency problems for that case. ... I suggest that you read the patch for the answer to softirq ...
    (Linux-Kernel)
  • Re: better wake-balancing: respin
    ... >>I guess I missed the objection for dropping the patch. ... correlation between the CPU the interrupt arrives on and the CPU the ... There is no point in immediate balancing either: ... If this patch hurts other workloads (and please ...
    (Linux-Kernel)
  • Re: Intel DG31PR and RTL8168/8111 issue
    ... The previous patch you used may have problems on multicast filtering. ... CPU supports Enhanced Speedstep, ... <ACPI PCI bus> on pcib0 ... hwrev = 38400000 ...
    (freebsd-stable)
  • Re: [PATCH] AMD Thermal Interrupt Support
    ... I'll add a robust description with the next revision of the patch. ... My buddy at Google suggested that I might as well fix this while I'm ... the throttling MCEs which you might naturally expect to see ... if you're expecting to be warned at 50C that your CPU has ...
    (Linux-Kernel)