lkml.org 
[lkml]   [2006]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: calibrate_migration_costs takes ages on s390

* David S. Miller <davem@davemloft.net> wrote:

> Things are not as slow, but definitely slow on sparc64 too, and it's
> also due to the migration cost calculations.
>
> It's also really bad that it's using vmalloc(), for one thing, because
> this thrashes the TLB (some of us have 64-entry software replaced
> TLBs) and also because you can make no guarentees about how well the
> backing physical pages will distribute into the L2 cache.

the TLB trashing is intended, to calculate the worst-case migration
cost. If userspace is TLB-intensive, it will trash TLBs just as much.

> As a result, wildly different run-to-run results can be expected
> particularly for systems with 1-way or 2-way set assosciative L2
> caches, which are common on sparc64. I don't know about s390.

s390 is clearly a special-base, being a virtual platform. But the
calibration should be improved to work better on sparc64.

Do things get better if you fill out include/asm-sparc64/system.h's
sched_cacheflush() function, to flush the L2 cache? That should at least
make the cache state more or less reproducable across runs.

Ingo
-
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/

\
 
 \ /
  Last update: 2006-02-13 11:58    [W:0.070 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site