* Andi Kleen ([EMAIL PROTECTED]) wrote:
> On Wednesday 20 June 2007 18:46, Mathieu Desnoyers wrote:
> > * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > > On Tuesday 19 June 2007 22:01:36 Mathieu Desnoyers wrote:
> > > > Looking more closely into the code to find the cause of the
> > > > change_page_add
On Wednesday 20 June 2007 18:46, Mathieu Desnoyers wrote:
> * Andi Kleen ([EMAIL PROTECTED]) wrote:
> > On Tuesday 19 June 2007 22:01:36 Mathieu Desnoyers wrote:
> > > Looking more closely into the code to find the cause of the
> > > change_page_addr()/global_flush_tlb() inconsistency, I see where
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> On Tuesday 19 June 2007 22:01:36 Mathieu Desnoyers wrote:
> > Looking more closely into the code to find the cause of the
> > change_page_addr()/global_flush_tlb() inconsistency, I see where the
> > problem could be:
>
> Yes it's a known problem. I have a
On Tuesday 19 June 2007 22:01:36 Mathieu Desnoyers wrote:
> Looking more closely into the code to find the cause of the
> change_page_addr()/global_flush_tlb() inconsistency, I see where the
> problem could be:
Yes it's a known problem. I have a hack queued for .22 and there
are proposed patches f
Looking more closely into the code to find the cause of the
change_page_addr()/global_flush_tlb() inconsistency, I see where the
problem could be:
In arch/i386/mm/pageattr.c:
__change_page_attr adds the page to the df_list for deferred removal
when it is replaced by a large page (going back to the
5 matches
Mail list logo
