linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Huang Pei <huangpei@loongson.cn>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: ambrosehua@gmail.com, Bibo Mao <maobibo@loongson.cn>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mips@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-mm@kvack.org, Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Paul Burton <paulburton@kernel.org>,
	Li Xuefeng <lixuefeng@loongson.cn>,
	Yang Tiezhu <yangtiezhu@loongson.cn>,
	Gao Juxin <gaojuxin@loongson.cn>,
	Fuxin Zhang <zhangfx@lemote.com>, Huacai Chen <chenhc@lemote.com>
Subject: Re: [PATCH V3] MIPS: make userspace mapping young by default
Date: Thu, 8 Oct 2020 11:30:43 +0800	[thread overview]
Message-ID: <20201008033043.x2fyc354ivjqyfe3@ambrosehua-HP-xw6600-Workstation> (raw)
In-Reply-To: <20201002123502.GA11098@alpha.franken.de>

On Fri, Oct 02, 2020 at 02:35:03PM +0200, Thomas Bogendoerfer wrote:
Hi, 
> On Sat, Sep 19, 2020 at 03:47:31PM +0800, Huang Pei wrote:
> > MIPS page fault path take 3 exceptions (1 TLB Miss + 2 TLB Invalid), but
> > the second TLB Invalid exception is just triggered by __update_tlb from
> > do_page_fault writing tlb without _PAGE_VALID set. With this patch, it
> > only take 1 TLB Miss + 1 TLB Invalid exceptions
> > 
> > This version removes pte_sw_mkyoung without polluting MM code and makes
> > page fault delay of MIPS on par with other architecture and covers both
> > no-RIXI and RIXI MIPS CPUS
> > 
> > [1]: https://lkml.kernel.org/lkml/1591416169-26666-1-git-send-email
> > -maobibo@loongson.cn/
> > ---
> > V3:
> > - reformat with whitespace cleaned up following Thomas's advice
> > V2:
> > - remove unused asm-generic definition of pte_sw_mkyoung following Mao's
> > advice
> > ---
> > Co-developed-by: Huang Pei <huangpei@loongson.cn>
> > Signed-off-by: Huang Pei <huangpei@loongson.cn>
> > Co-developed-by: Bibo Mao <maobibo@loonson.cn>
> > ---
> >  arch/mips/include/asm/pgtable.h | 10 ++++------
> >  arch/mips/mm/cache.c            | 25 +++++++++++++------------
> >  include/linux/pgtable.h         |  8 --------
> >  mm/memory.c                     |  3 ---
> >  4 files changed, 17 insertions(+), 29 deletions(-)
> > 
> > diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
> > index dd7a0f552cac..931fb35730f0 100644
> > --- a/arch/mips/include/asm/pgtable.h
> > +++ b/arch/mips/include/asm/pgtable.h
> > @@ -27,11 +27,11 @@ struct vm_area_struct;
> >  
> >  #define PAGE_NONE	__pgprot(_PAGE_PRESENT | _PAGE_NO_READ | \
> >  				 _page_cachable_default)
> > -#define PAGE_SHARED	__pgprot(_PAGE_PRESENT | _PAGE_WRITE | \
> > -				 _page_cachable_default)
> > +#define PAGE_SHARED    __pgprot(_PAGE_PRESENT | _PAGE_WRITE | \
> > +				 __READABLE | _page_cachable_default)
> 
> you are still doing a white space changes here. 
> 
> >  #define PAGE_COPY	__pgprot(_PAGE_PRESENT | _PAGE_NO_EXEC | \
> > -				 _page_cachable_default)
> > -#define PAGE_READONLY	__pgprot(_PAGE_PRESENT | \
> > +				 __READABLE | _page_cachable_default)
> > +#define PAGE_READONLY	__pgprot(_PAGE_PRESENT |  __READABLE | \
> 
sorry, my bad
> I've grepped for usage of PAGE_SHARED and PAGE_READONLY and found
> arch/mips/kvm/mmu.c and arch/mips/kernel/vdso.c. I wonder
> 
for arch/mips/kvm/mmu.c, the comment says:
...
	/* Also set valid and dirty, so refill handler doesn't have to */
	*ptep = pte_mkyoung(pte_mkdirty(pfn_pte(pfn, PAGE_SHARED)));
...
the net effect is the same, dirty and valid, so I think it is ok;

for arch/mips/kernel/vdso.c, both mappings are kernel mapping, which
means the physical memory(or io memory) is already allocated and will not
be reclaimed by kernel.
       
> 1. Is this usage correct or should we use protection_map[X] ?
> 2. Are this still correct after the change in this patch ?
> 
> Right now I'm in favour to fist clean up asm/pgtable.h to get rid
> of all unneeded PAGE_XXX defines and make mm/cache.c rixi part
> more readable before applying this patch.
>
I think we can clean up rixi part of mm/cache.c after this patch, or
within V4;

> Thomas.
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]


      reply	other threads:[~2020-10-08  3:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-19  7:47 [PATCH V3] MIPS: make userspace mapping young by default Huang Pei
2020-09-28  6:39 ` Huang Pei
2020-10-02 12:35 ` Thomas Bogendoerfer
2020-10-08  3:30   ` Huang Pei [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201008033043.x2fyc354ivjqyfe3@ambrosehua-HP-xw6600-Workstation \
    --to=huangpei@loongson.cn \
    --cc=akpm@linux-foundation.org \
    --cc=ambrosehua@gmail.com \
    --cc=chenhc@lemote.com \
    --cc=gaojuxin@loongson.cn \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lixuefeng@loongson.cn \
    --cc=maobibo@loongson.cn \
    --cc=paulburton@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=yangtiezhu@loongson.cn \
    --cc=zhangfx@lemote.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).