On 8/1/07, Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
> You do have model specific I cache semantics.
> Not taking it into account will oblige you to flush in vain for the models
> which do not require it. Why do you want to take this option?
Given unlimited resources, your proposal makes perfect
Luck, Tony wrote:
This seems crazy to me. Flushing should occur according to the
*architecture*, not model-by-model. Even if we happen to get "lucky"
on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you
really want to debug this *again* come next CPU?
Ditto. The only reason
Jim Hull wrote:
Not just crazy, but wrong - this *can* happen on pre-Montecito. Even though
L1D is write-through and L2 was mixed I/D, the L1 I-cache could contain
stale instrutions if there are missing flushes.
I cannot agree with you.
In order to consider an L1 I-cache entry as valid, a cor
MAIL PROTECTED];
> [EMAIL PROTECTED]; Christoph Lameter
> Subject: Re: [PATCH] flush icache before set_pte take6. [4/4]
> optimization for cpus other than montecito
>
> On Mon, 30 Jul 2007 22:15:50 -0600
> "David Mosberger-Tang" <[EMAIL PROTECTED]> wrote:
>
>
> This seems crazy to me. Flushing should occur according to the
> *architecture*, not model-by-model. Even if we happen to get "lucky"
> on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you
> really want to debug this *again* come next CPU?
Ditto. The only reason we should ever
KAMEZAWA Hiroyuki wrote:
Could we discuss this in other thread as "optimization for some cpus" and
push bug-fix patches first ?
If take5 or part of take6(patch 1,2) are not acceptable, I'll continue this
work on -rc2.
Thanks,
-Kame
Sure.
Thanks,
Zoltan
-
To unsubscribe from this list: send
On Tue, 31 Jul 2007 10:38:48 +0200
Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
> David Mosberger-Tang wrote:
> > This seems crazy to me. Flushing should occur according to the
> > *architecture*, not model-by-model. Even if we happen to get "lucky"
> > on pre-Montecito CPUs, that doesn't justify
David Mosberger-Tang wrote:
This seems crazy to me. Flushing should occur according to the
*architecture*, not model-by-model. Even if we happen to get "lucky"
on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you
really want to debug this *again* come next CPU?
--david
O.K.
On Tue, 31 Jul 2007 13:29:32 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> On Mon, 30 Jul 2007 22:15:50 -0600
> "David Mosberger-Tang" <[EMAIL PROTECTED]> wrote:
>
> > This seems crazy to me. Flushing should occur according to the
> > *architecture*, not model-by-model. Even if we happen
On Mon, 30 Jul 2007 22:15:50 -0600
"David Mosberger-Tang" <[EMAIL PROTECTED]> wrote:
> This seems crazy to me. Flushing should occur according to the
> *architecture*, not model-by-model. Even if we happen to get "lucky"
> on pre-Montecito CPUs, that doesn't justify such ugly hacks.
I'm not s
This seems crazy to me. Flushing should occur according to the
*architecture*, not model-by-model. Even if we happen to get "lucky"
on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you
really want to debug this *again* come next CPU?
--david
On 7/30/07, KAMEZAWA Hiroyuki <[EMA
Add "L2 cache is separated? check flag" as read_mostly global variable.
This add one memory reference to global variable to page faults of "executable"
map in do_wp_page(page copy case), file-mapped page fault and some system calls
which does memory map changes. But not so bad as calling sync_ica
12 matches
Mail list logo
