From: James Bottomley <James.Bottomley@steeleye.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Andrea Arcangeli <andrea@suse.de>,
Linux Kernel <linux-kernel@vger.kernel.org>,
parisc-linux@parisc-linux.org
Subject: Re: [parisc-linux] rmap: parisc __flush_dcache_page
Date: 08 Apr 2004 09:40:37 -0500 [thread overview]
Message-ID: <1081435237.1885.144.camel@mulgrave> (raw)
In-Reply-To: <Pine.LNX.4.44.0404081500520.7116-100000@localhost.localdomain>
On Thu, 2004-04-08 at 09:16, Hugh Dickins wrote:
> Don't be afraid, that's good! Is it still going vertically down
> i_mmap_shared and i_mmap? Whereas it's only interested in vmas of
> the one mm, so could go horizontally along it. Just an option to
> play with, but I don't believe it solves anything, just as unsafe
> when threaded.
Yes, I've attached the current code. I'm afraid we have space
separation in our caches and tlbs, so we're interested in all mm's not
just the current one (that was the bug that just got fixed).
> Which we're not giving you at all at present. I guess another layer
> of spinlocking/nopreemption, for parisc and arm, dissolving to nothing
> on other arches.
Whatever seems most convenient that won't impact the flushing fast path,
I suppose. It's one of the hottest paths in the system since all data
transfers go through it for user visibility.
James
__flush_dcache_page(struct page *page)
{
struct mm_struct *mm = current->active_mm;
struct list_head *l;
struct vm_area_struct *anyvma = NULL;
flush_kernel_dcache_page(page_address(page));
if (!page->mapping)
return;
/* We have ensured in arch_get_unmapped_area() that all shared
* mappings are mapped at equivalent addresses, so we only need
* to flush one for them all to become coherent */
list_for_each(l, &page->mapping->i_mmap_shared) {
struct vm_area_struct *mpnt;
unsigned long off, addr;
mpnt = list_entry(l, struct vm_area_struct, shared);
if (page->index < mpnt->vm_pgoff)
continue;
off = page->index - mpnt->vm_pgoff;
if (off >= (mpnt->vm_end - mpnt->vm_start) >> PAGE_SHIFT)
continue;
addr = mpnt->vm_start + (off << PAGE_SHIFT);
/* flush instructions produce non access tlb misses.
* On PA, we nullify these instructions rather than
* taking a page fault if the pte doesn't exist, so we
* have to find a congruent address with an existing
* translation */
if (!translation_exists(mpnt, addr))
continue;
anyvma = mpnt;
/*
* We try first to find a page in our current user process
*/
if (mpnt->vm_mm != mm)
continue;
__flush_cache_page(mpnt, addr);
/* All user shared mappings should be equivalently mapped,
* so once we've flushed one we should be ok
*/
goto flush_unshared;
}
/* OK, shared page but not in our current process' address space */
if (anyvma) {
unsigned long addr = anyvma->vm_start
+ ((page->index - anyvma->vm_pgoff) << PAGE_SHIFT);
__flush_cache_page(anyvma, addr);
}
flush_unshared:
/* Private mappings will not have congruent addresses, so we
* have to flush each of them individually to make the change
* in the kernel page visible */
list_for_each(l, &page->mapping->i_mmap) {
struct vm_area_struct *mpnt;
unsigned long off, addr;
mpnt = list_entry(l, struct vm_area_struct, shared);
if (page->index < mpnt->vm_pgoff)
continue;
off = page->index - mpnt->vm_pgoff;
if (off >= (mpnt->vm_end - mpnt->vm_start) >> PAGE_SHIFT)
continue;
addr = mpnt->vm_start + (off << PAGE_SHIFT);
/* This is just for speed. If the page translation isn't
* there there's no point exciting the nadtlb handler into
* a nullification frenzy */
if(!translation_exists(mpnt, addr))
continue;
__flush_cache_page(mpnt, addr);
}
}
next prev parent reply other threads:[~2004-04-08 15:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-08 13:41 rmap: parisc __flush_dcache_page Hugh Dickins
2004-04-08 13:52 ` [parisc-linux] " James Bottomley
2004-04-08 14:16 ` Hugh Dickins
2004-04-08 14:40 ` James Bottomley [this message]
2004-04-08 15:14 ` Andrea Arcangeli
2004-04-08 15:28 ` James Bottomley
2004-04-08 15:34 ` Andrea Arcangeli
2004-04-08 15:47 ` James Bottomley
2004-04-08 16:16 ` Andrea Arcangeli
2004-04-08 16:29 ` James Bottomley
2004-04-08 17:10 ` Andrea Arcangeli
2004-04-08 17:43 ` James Bottomley
2004-04-08 17:51 ` Andrea Arcangeli
2004-04-08 18:07 ` James Bottomley
2004-04-08 18:18 ` Andrea Arcangeli
2004-04-08 18:28 ` James Bottomley
2004-04-08 18:42 ` Andrea Arcangeli
2004-04-08 18:49 ` James Bottomley
2004-04-08 19:02 ` Andrea Arcangeli
2004-04-10 1:21 ` Paul E. McKenney
2004-04-08 15:35 ` Hugh Dickins
2004-04-08 16:13 ` Andrea Arcangeli
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=1081435237.1885.144.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=andrea@suse.de \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=parisc-linux@parisc-linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox