Re: 2.6.2-rc1-mm2

From: john stultz (johnstul_at_us.ibm.com)
Date: 01/23/04

  • Next message: Alan Stern: "Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core" 
    To: Thomas Schlichter <thomas.schlichter@web.de>
Date:	Fri, 23 Jan 2004 09:59:28 -0800

    On Fri, 2004-01-23 at 05:30, Thomas Schlichter wrote:
    > Hi,
    >
    > Am Freitag, 23. Januar 2004 10:37 schrieb Andrew Morton:
    > > +use-pmtmr-for-delay_pmtmr.patch
    > >
    > > Fix a boot-time crash which occurs when testing the APIC timer when using
    > > the ACPI PM timer. This causes bogomips to be reported at 50% of what it
    > > used to be.
    >
    > I don't know which Oops this fixes, but with this patch my bogomips value is
    > 8.19 (!!!) instead of ~1300. With clock=pit I get about 1300 bogomips, and
    > with clock=tsc I get about 2600 bogomips. The CPU is a 1300MHz AMD Duron.

    I know it feels like a kick in the pants when your BogoMIPS drops to
    leves not seen since the 80s, but the value you are getting is expected.
    Since the patch above uses the pmtmr for __delay(), loops_per_jiffies is
    then calibrated to the ACPI PM timer's frequency instead of aproximately
    the cpu's freq.

    This was necessary, because on some systems calibrate_dealy()
    incorrectly calibrates delays. Your system shows this, but its your
    cycle based delay (clock=tsc) which is overestimated, so you see no
    problem. The case Andrew describes above is when the loop based delay
    (clock=pit or clock=pmtmr w/o this patch) is under estimated causing
    problems when we initialize the APIC timer.

    Additionally, since we're no longer dependent on the cpu speed,
    speedstep like changes to the cpu freqency no longer affects time.

    thanks
    -john

    -
    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: Alan Stern: "Re: PATCH: (as177) Add class_device_unregister_wait() and platform_device_unregister_wait() to the driver model core"

    Relevant Pages

    • Re: [2.6 patch] i386: always use 4k stacks
      ... > Maybe a good deal would be to delay the 4K patch until some preliminary ... questions on `make *config` so that sufficiently interesting people must ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered
      ... > I have updated the apic timer ack delay patch and the io-apic edge patch ... > of the delay time expiring naturally and the less the impact of the patch. ... > The apic timer counts down from the reload value and interrupts at zero. ... > than that is expected to be when it is safe to ack the local apic after an apic ...
      (Linux-Kernel)
    • Re: [-mm patch 5/5] SharpSL: Add new ARM PXA machines Spitz and Borzoi with partial Akita Support
      ... would you accept a patch to add an optional delay option ... +void mmc_detect_change(struct mmc_host *host, unsigned long delay) ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] Delay accounting, fix incorrect delay time when constantly waiting on runqueue
      ... This patch corrects the incorrect value of per process run-queue wait time ... reported by delay statistics. ... When a process leaves the CPU and immediately starts waiting for CPU on ... The patch was tested on 2.6.26-rc6 using two simple CPU hog programs. ...
      (Linux-Kernel)
    • [V, mostly] Patch for movement controls.
      ... To celebrate the release of V 3.0.8, and to make bug reporting for that more complicated than it has to be, I've written a patch to the Angband movement/targeting/direction-choosing system. ... It adds a new option to the options menu, which is the amount of time in centiseconds to wait for a second keypress before acting on the first when in "movement" situations, such as walking, running, choosing a direction to fire something, and so on. ... I've found 8 to be the absolute minimum delay to make it reliably usable on a reasonably unlaggy SSH connection, and the maximum very much depends on how long you're prepared to wait between each step. ...
      (rec.games.roguelike.angband)