Re: HT schedulers' performance on single HT processor

From: Con Kolivas (kernel_at_kolivas.org)
Date: 12/16/03

  • Next message: Admin: "Attention All School Staff, Personnel, and Students:" 
    Date:	Tue, 16 Dec 2003 11:55:02 +1100
To: Nathan Fredrickson <8nrf@qlink.queensu.ca>

    Quoting Nathan Fredrickson <8nrf@qlink.queensu.ca>:
    > X = 1 2 3 4 5 6 7 8 9 16
    > 1phys UP 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00
    > 4phys SMP 1.00 0.99 0.51 0.35 0.27 0.27 0.27 0.27 0.27 0.27
    > 4phys HT 1.01 1.00 0.55 0.40 0.33 0.29 0.27 0.26 0.25 0.26
    > 4phys HT(w26) 1.01 1.01 0.54 0.37 0.31 0.27 0.26 0.26 0.26 0.26
    > 4phys HT(C1) 1.01 1.00 0.52 0.36 0.29 0.28 0.27 0.26 0.25 0.26
    >
    > Interesting that the overhead due to HT in the X=1 column is only 1%
    > with 4 physical processors. It was 1-3% before with 1 or 2 physical
    > processors.
    >
    > In the partial load columns where there are less compiler processes than
    > logical CPUs (X=3,4,5,6,7), it appears that both patches are doing a
    > better job scheduling than the standard scheduler. At full load (X=>8)
    > all three HT test cases perform about equally and beat standard SMP by
    > 1-2%.
    >
    > Hope these results are helpful. I'd be happy to run more cases and/or
    > other patches.

    (cc list stripped)

    Well since you asked... I've been looking for someone with more HT cpus to give
    a much simpler approach a try. Here's a sample patch for vanilla test11 with
    HT. This one actually helps UP HT performance ever so slightly and I'd be
    curious to see if it does anything on more cpus.

    Con

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Admin: "Attention All School Staff, Personnel, and Students:"

    Relevant Pages

    • Re: [PATCH] fix schedstats null deref in sched_exec
      ... I meant to send this one with my original patchset. ... > during testing of the previous patches where cpus are temporarily ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC 0/4] dynamically allocate arch specific system vectors
      ... I need to look at these patches some more. ... The last patch adds the dynamic allocate of system irq, which, if I'm ... So we can only assign to cpus that are online now. ... And latter add the other cpus when they come online. ...
      (Linux-Kernel)
    • Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata
      ... This buys nothing on CPUs which don't have the ... We have always built kernels that contained the support for older chips. ... difference in the real world between PIV and PIV with 100 bytes of extra ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [PATCH 0/3] Resend: Discard reserved PXM bits for SRAT v1
      ... I applied the three patches against 2.6.30-git14. ... cpu1 cpu3 cpumap meminfo scan_unevictable_pages ... Where as, before, it looked like this (non-ordered, all CPUs showing up ...
      (Linux-Kernel)
    • RE: CONFIG_IRQBALANCE for AMD64?
      ... Provide some sort of cache-affinity for network interrupt processing, ... Utilize idle CPUs where possible to shoulder the load. ... I'll confess to not having looked at non-i386 arches. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    Loading