All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/9] mm: arm ready for split ptlock
Date: Sat, 22 Oct 2005 18:02:40 +0100	[thread overview]
Message-ID: <20051022170240.GA10631@flint.arm.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.61.0510221719370.18047@goblin.wat.veritas.com>

On Sat, Oct 22, 2005 at 05:22:20PM +0100, Hugh Dickins wrote:
> Signal handling's preserve and restore of iwmmxt context currently
> involves reading and writing that context to and from user space, while
> holding page_table_lock to secure the user page(s) against kswapd.  If
> we split the lock, then the structure might span two pages, secured by
> different locks.  That would be manageable; but it seems simpler just
> to read into and write from a kernel stack buffer, copying that out and
> in without locking (the structure is 160 bytes in size, and here we're
> near the top of the kernel stack).  Or would the overhead be noticeable?

Please contact Nicolas Pitre about that - that was my suggestion,
but ISTR apparantly the overhead is too high.

> arm_syscall's cmpxchg emulation use pte_offset_map_lock, instead of
> pte_offset_map and mm-wide page_table_lock; and strictly, it should now
> also take mmap_sem before descending to pmd, to guard against another
> thread munmapping, and the page table pulled out beneath this thread.

Now that I look at it, it's probably buggy - if the page isn't already
dirty, it will modify without the COW action.  Again, please contact
Nicolas about this.

> Updated two comments in fault-armv.c.  adjust_pte is interesting, since
> its modification of a pte in one part of the mm depends on the lock held
> when calling update_mmu_cache for a pte in some other part of that mm.
> This can't be done with a split page_table_lock (and we've already taken
> the lowest lock in the hierarchy here): so we'll have to disable split
> on arm, unless CONFIG_CPU_CACHE_VIPT to ensures adjust_pte never used.

Well, adjust_pte is extremely critical to ensure correct cache behaviour
(and therefore data integrity) so if split ptlock is incompatible with
this, split ptlock loses.

As far as adjust_pte being called, it's only called for VIVT caches,
which means the configuration has to do if VIVT, disable split ptlock.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

  reply	other threads:[~2005-10-22 17:02 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-22 16:18 [PATCH 0/9] mm: page fault scalability Hugh Dickins
2005-10-22 16:19 ` [PATCH 1/9] mm: i386 sh sh64 ready for split ptlock Hugh Dickins
2005-10-22 18:24   ` Paul Mundt
2005-10-22 16:22 ` [PATCH 2/9] mm: arm " Hugh Dickins
2005-10-22 17:02   ` Russell King [this message]
2005-10-23  8:27     ` Hugh Dickins
2005-10-25  2:45     ` Nicolas Pitre
2005-10-25  6:31       ` Hugh Dickins
2005-10-25 14:55         ` Nicolas Pitre
2005-10-25  7:55       ` Russell King
2005-10-25 15:00         ` Nicolas Pitre
2005-10-26  0:20           ` Russell King
2005-10-26  1:26             ` Nicolas Pitre
2005-10-31 22:19             ` Jesper Juhl
2005-10-31 22:27               ` Russell King
2005-10-31 22:34                 ` Jesper Juhl
2005-10-31 22:50                   ` Russell King
2005-10-22 16:23 ` [PATCH 3/9] mm: parisc pte atomicity Hugh Dickins
2005-10-22 16:33   ` [parisc-linux] " Matthew Wilcox
2005-10-22 16:33   ` Matthew Wilcox
2005-10-22 17:08     ` [parisc-linux] " James Bottomley
2005-10-22 17:08     ` James Bottomley
2005-10-23  9:02       ` Hugh Dickins
2005-10-23 15:05         ` James Bottomley
2005-10-24  4:36           ` Hugh Dickins
2005-10-24  4:36           ` Hugh Dickins
2005-10-24 14:56             ` James Bottomley
2005-10-24 16:49               ` Hugh Dickins
2005-10-24 16:49               ` Hugh Dickins
2005-10-24 14:56             ` James Bottomley
2005-10-23  9:02       ` Hugh Dickins
2005-10-22 16:24 ` [PATCH 4/9] mm: cris v32 mmu_context_lock Hugh Dickins
2005-10-22 16:25 ` [PATCH 5/9] mm: uml pte atomicity Hugh Dickins
2005-10-22 16:27 ` [PATCH 6/9] mm: uml kill unused Hugh Dickins
2005-10-22 19:23   ` Jeff Dike
2005-10-22 16:29 ` [PATCH 7/9] mm: split page table lock Hugh Dickins
2005-10-23 16:54   ` Nikita Danilov
2005-10-23 21:27   ` Andrew Morton
2005-10-23 22:22     ` Andrew Morton
2005-10-24  3:38       ` Hugh Dickins
2005-10-24  4:16         ` Andrew Morton
2005-10-24  4:58           ` Hugh Dickins
2005-10-24  3:09     ` Hugh Dickins
2005-10-23 21:49   ` Andrew Morton
2005-10-24  3:12     ` Hugh Dickins
2005-10-22 16:30 ` [PATCH 8/9] mm: fix rss and mmlist locking Hugh Dickins
2005-10-22 16:31 ` [PATCH 9/9] mm: update comments to pte lock Hugh Dickins
2005-10-23  7:49 ` [PATCH 6/9 take 2] mm: uml kill unused Hugh Dickins

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=20051022170240.GA10631@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=akpm@osdl.org \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.