[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49DCDFC9.9000505@goop.org>
Date: Wed, 08 Apr 2009 10:32:57 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Ingo Molnar <mingo@...e.hu>
CC: Andrew Morton <akpm@...ux-foundation.org>,
the arch/x86 maintainers <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Nick Piggin <nickpiggin@...oo.com.au>,
Thomas Gleixner <tglx@...utronix.de>,
David Howells <dhowells@...hat.com>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>
Subject: Re: [PATCH] Allow preemption during lazy mmu updates
Ingo Molnar wrote:
> * Jeremy Fitzhardinge <jeremy@...p.org> wrote:
>
>
>> include/asm-frv/pgtable.h | 4 +-
>>
>
> Needs the ack of the FRV arch maintainer both for content and for
> flow (i.e. via x86 tree). If any second thoughts are expressed about
> the flow then this needs to go on separate tracks.
>
I don't know why frv defines this; its just cut'n'paste from the default
no-op implementation in asm-generic/pgtable.h. (h8300 too, it seems.)
David, do you have a specific reason for defining
arch_enter/leave_lazy_cpu_mode() in asm-frv/pgtable.h? It seems to have
come in with 28936117af849b8c2fca664a41ea7651a0d99591 "FRV: Add some
missng lazy MMU hooks for NOMMU mode". The intention was that
asm-generic/pgtable.h should supply the default definitions; is that
incompatible with nommu or something?
Yoshinori-san, do you have a specific reason for defining
arch_enter/leave_lazy_cpu_mode() in asm-h3800/pgtable.h? It seems to
have come in with c728d60455e8e8722ee08312a75f38dd7a866b5e "h8300
generic irq", which doesn't seem like a related change.
>> include/asm-generic/pgtable.h | 21 +++++++------
>>
>
> Needs the ack of arch maintainers in general and a linux-arch
> cross-post.
>
asm-generic/pgtable.h defines the default no-op implementation which is
used when the architecture has no particular use for the hook. The only
non-x86 definitions are frv and h3800, and they're both copies of the
no-op definition.
In any case, if this series is a sticking point, we can easily drop it
as the subsequent patches have no dependency on it.
J
--
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