LKML Archive on
help / color / mirror / Atom feed
From: Zoltan Menyhart <>
To: KAMEZAWA Hiroyuki <>
Subject: Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path
Date: Thu, 05 Jul 2007 10:57:00 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

KAMEZAWA Hiroyuki wrote:
> On Wed, 04 Jul 2007 16:24:38 +0200
> Zoltan Menyhart <> wrote:
>>Machines star up whit bit 5 = 0, reading instruction pages via
>>NFS has to flush them from L2I.
> In our test, we confirmed that this can be fixed by flushing L2I just before 
> SetPageUptodate() in NFS.

I can agree.
We can be more permissive: it can be done anywhere after the new
data is put in place and before nfs_readpage() or nfs_readpages()

I saw your patch
that modifies e.g. mm/memory.c and not the NFS layer.

Have you proposed a patch against the NFS layer?

>>I was wondering if instead of modifying do_no_page() and Co., should
>>not we make nfs_readpage() be DMA-like?
>>(No possible regression for most of the page I/O-s.)
>>I.e. it should be the responsibility of a file system to make sure it
>>supports instruction pages correctly. The base kernel should provide
>>such file systems with an architecture dependent macro...
> IMHO, for example, race in cooy-on-write  (was fixed by Tony Luck) has to be
> fixed by MemoryManagement layer.

I can agree.
Note that it has not got much performance impact from our point
of view because there are not too many COW paves with executable code...

> And only a race in do_no_page() seems to be able to be fixed by FS layer.

If it were do_no_page() that would fix the problem, then it should know
where the page comes from in order not to flush the I-cache in vain.
do_no_page() just calls vma->vm_ops->nopage() that goes down to
fs_op->readpage() / fs_op->readpages().

On the other hand, these latter routines do not know why they fetch
the page(s). Note that a page can be mapped more than one times, with
different permission bits.
As a consequence, these routines will flush the I-cache in vain in
most of the cases.

I prefer a performance impact to some non DMA based file systems
and adding nothing to the path for the majority of the cases.

> BTW, can we know whether a page is filled by DMA or not  ?

Well, the file systems based on block devices use DMA transfer
(with the exception of using bounce buffers, in that case it is the
responsibility of the bounce buffering layer to flush the I-cache).

Network based file systems require revision and update...

Note that only the processors with separate L2I require
attention, the L1I is guaranteed to be flushed when you change
the corresponding TBL entry.

The base kernel should provide a macro / service (that cares for the
processor model) for the file systems.


Zoltan Menyhart

  reply	other threads:[~2007-07-05  8:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-04 14:24 Zoltan Menyhart
2007-07-04 16:58 ` KAMEZAWA Hiroyuki
2007-07-05  8:57   ` Zoltan Menyhart [this message]
2007-07-05 17:36     ` Mike Stroyan
     [not found] <>
2007-04-26  7:53 ` Nick Piggin
2007-04-26 17:35   ` Mike Stroyan
2007-04-27 11:55     ` Nick Piggin
2007-04-27 14:18       ` Hugh Dickins
2007-04-27 17:02         ` David Mosberger-Tang
2007-04-28  1:31         ` Rohit Seth
2007-04-28  5:34           ` Hugh Dickins
2007-04-28 18:17             ` Rohit Seth
2007-05-01 11:52               ` Nick Piggin
2007-05-02  0:36                 ` Rohit Seth
2007-05-02  2:05                   ` Nick Piggin
2007-04-28  2:16         ` Nick Piggin
2007-04-28  1:24       ` Rohit Seth
2007-04-28  2:00         ` Nick Piggin
2007-04-28  3:04           ` Nick Piggin
2007-04-28  5:20             ` Hugh Dickins
2007-04-28  6:03               ` Nick Piggin
2007-04-28 18:30                 ` Rohit Seth
2007-05-01 11:47                   ` Nick Piggin
2007-05-02  0:36                     ` Rohit Seth
2007-04-28 18:05               ` Rohit Seth
2007-05-01 11:43                 ` Nick Piggin
2007-05-04 21:32                   ` Mike Stroyan
2007-04-28  4:11           ` Nick Piggin
2007-04-28 17:57           ` Rohit Seth
2007-05-01 11:39             ` Nick Piggin
2007-05-02  0:36               ` Rohit Seth
2007-05-02  1:57                 ` Nick Piggin

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:

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

  git send-email \ \ \ \ \ \
    --subject='Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).