LinuxLists.cc - 2.6.14-rc2-mm1

Subject: Re: 2.6.14-rc2-mm1

On Mon, Sep 26, 2005 at 09:14:02AM +0200, Tim Schmielau wrote:
> On Sun, 25 Sep 2005, Paul Blazejowski wrote:
>
> > Upon quick testing the latest mm kernel it appears there's some kind of
> > race condition when using dual core cpu esp when using XORG and USB
> > (although PS2 has same issue) kebyboard rate being too fast.
>
> Does the following patch by John Stultz fix the problem?
>
> Tim

Tim,

No it does not, from my understanding it only pertains to x86_64 but
currently i run i386 SMP enabled kernel on the dualcore X2 processor.

Also worth noting is that i do not see any failures or errors in dmesg
related to lost timers. Perhaps this is something new? I even run a
script from the bugzilla and the output matched both cpu's.

Thanks,

Paul

>
>
> From [email protected] Mon Sep 26 09:04:08 2005
> Date: Mon, 19 Sep 2005 12:16:43 -0700
> From: john stultz <[email protected]>
> To: Andrew Morton <[email protected]>
> Cc: lkml <[email protected]>, Andi Kleen <[email protected]>
> Subject: [PATCH] x86-64: Fix bad assumption that dualcore cpus have synced
> TSCs
>
> Andrew,
> This patch should resolve the issue seen in bugme bug #5105, where it
> is assumed that dualcore x86_64 systems have synced TSCs. This is not
> the case, and alternate timesources should be used instead.
>
> For more details, see:
> http://bugzilla.kernel.org/show_bug.cgi?id=5105
>
>
> Please consider for inclusion in your tree.
>
> thanks
> -john
>
> diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
> --- a/arch/x86_64/kernel/time.c
> +++ b/arch/x86_64/kernel/time.c
> @@ -959,9 +959,6 @@ static __init int unsynchronized_tsc(voi
> are handled in the OEM check above. */
> if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
> return 0;
> - /* All in a single socket - should be synchronized */
> - if (cpus_weight(cpu_core_map[0]) == num_online_cpus())
> - return 0;
> #endif
> /* Assume multi socket systems are not synchronized */
> return num_online_cpus() > 1;
>
>
>

Attachments:

(No filename) (1.98 kB)
(No filename) (189.00 B)
Download all attachments

2005-09-28 04:56:44

> mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk patch tries to
> allocate more physical contiguous pages for pcp. This would cause some
> extra fragmentation at the higher orders but has the potential benefit
> of spreading more uniformly across caches. I agree though that for this
> scheme to work nicely we should have the capability of draining the pcps
> so that higher order requests can be serviced whenever possible.

Unfortunately, I don't think it's that simple. We'll end up taking the
higher order elements from the buddy into the caches, and using them
all piecemeal - ie fragmenting it all.

If we take lists of 0 order pages from the buddy, we're trying to use
whatever dross was left over in there (from a fragmentation point of view)
up first, before breaking into the more precious stuff (phys contig bits).

That was why I wrote it that way in the first place - it wasn't
accidental ;-)

>From the direction the thread was going in previously, it sounded like
you were finding other ways to alleviate the colouring issue you were
seeing ... I was hoping that would fix it up enough the desire for higher
order allocations would disappear.

To be blunt about it ... making sure that we don't fall over on higher
order allocs seems to me to be more important than a bit of variability
in benchmark runs ...

M.