[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AF233D1473C1364ABD51D28909A1B1B73259A4FF@pgsmsx105.gar.corp.intel.com>
Date: Tue, 30 Sep 2014 01:46:04 +0000
From: "Ong, Boon Leong" <boon.leong.ong@...el.com>
To: "'pure.logic@...us-software.ie'" <pure.logic@...us-software.ie>,
Henrique de Moraes Holschuh <hmh@....eng.br>
CC: "hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"davej@...hat.com" <davej@...hat.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] x86: Quark: Add if/else to setup_arch for Quark TLB
bug
>
> My view is that the CR3 load should have flushed the TLB in it's entirety.
>
> Ong Boong Leong said that a discussion he had which included HPA concluded
> with a flush of the TLB being required after the CR3 reload.
The proposed patch was discussed in April and after much thought into this,
I will suggest that as long as the commentary properly captured down why
__flush_tlb() is **NOT** needed because load_cr3() will have the same effect.
>
> The current code
>
> My preference is
>
> 1. Just comment the code as is to explain why it works for Quark.
>
> If that's not good enough for people then
>
> 2. if/else the flow so that Quark does __flush_tlb() and the rest of the world
> does a __flush_tlb_all()
Bryan, just drop this proposal from my submission even though __flush_tlb() is
more obvious in what is supposed to do and does not consume any significant cpu-time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists