linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ilya Loginov <isloginov@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>, linux-arch@vger.kernel.org
Subject: Re: problems in commit 2d4dc890b5c8 (block: add helpers to run flush_dcache_page() against a bio and a request's pages)
Date: Wed, 09 Dec 2009 17:11:13 -0600	[thread overview]
Message-ID: <1260400273.14369.52.camel@mulgrave.site> (raw)
In-Reply-To: <20091210020309.36742c7f.isloginov@gmail.com>

On Thu, 2009-12-10 at 02:03 +0300, Ilya Loginov wrote:
> On Wed, 09 Dec 2009 16:39:06 -0600
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > Then this extra helpers added to block: rq_flush_dcache_pages() loops
> > over every segment of the request calling flush_dcache_page() for the
> > page.  If you read the mtd code, it acts on a bio at a time so a request
> > with N bios flushes every page in the request N times (i'e N^2 flushes).
> > I'm assuming there's something somewhere I'm missing that restricts mtd
> > to single bio requests, which makes this all OK?
> 
> Sorry. But why do you think that do_blktrans_request is dealing with bio?
> May be i don't know something...

I was basing it on the fact that req->data is bio_data() which is
initialised per bio.  What mtd does can't really work unless it's doing
a bio at a time (or has small limits so that all requests are bios).

> > The pio read case is the problematic one, because you dirty the kernel
> > alias by writing the read data to it and have to flush that before it's
> > made visible to the user alias view.  The API for doing this is
> > flush_kernel_dcache_page() ... it *only* flushes the kernel view, not
> > the user view.  The reason for this is that if the arch has to protect
> > the user aliases against speculative movein, that's done in the DMA API
> > before the request is completed.
> > 
> > So for this:
> > 
> > >	case READ:
> > >		for (; nsect > 0; nsect--, block++, buf += tr->blksize)
> > >			if (tr->readsect(dev, block, buf))
> > >				return -EIO;
> > >+		rq_flush_dcache_pages(req);
> > >		return 0;
> > 
> > Actually all you need to do is loop over the pages and call
> > flush_kernel_dcache_page().
> 
> I don't think so. Please reread our discussion.

As I said previously, I seem to have missed the discussion.

>  I have this bug on system where
> icache don't look for code in dcache. And I need flush dcache exactly in
> physical layer.

icache and dcache are usually separate.  On almost every architecture
you have to flush the dcache to RAM before the icache can pull it in.
However, think about where the data is in the pio read case:  it's in
the cache above the kernel alias.  Once you flush that cache to ram, the
icache can pick it out ... you don't have to reflush all the untouched
user aliases, you just use flush_kernel_dcache_page() which places it in
the ram.

James

  reply	other threads:[~2009-12-09 23:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-09 22:39 problems in commit 2d4dc890b5c8 (block: add helpers to run flush_dcache_page() against a bio and a request's pages) James Bottomley
2009-12-09 22:45 ` Russell King
2009-12-09 22:56   ` James Bottomley
2009-12-09 23:03 ` Ilya Loginov
2009-12-09 23:11   ` James Bottomley [this message]
2009-12-09 23:36     ` Ilya Loginov
2009-12-09 23:47       ` James Bottomley
2009-12-10  0:06         ` Ilya Loginov
2009-12-10  0:19           ` James Bottomley
2009-12-10  4:40             ` Ilya Loginov
2009-12-10 17:07               ` James Bottomley
2009-12-10 17:48                 ` Russell King
2009-12-10 17:59                   ` James Bottomley
2009-12-10 18:06                     ` Russell King
2009-12-10 18:20                       ` James Bottomley
2009-12-10 19:05                         ` Russell King
2009-12-10 20:29                           ` James Bottomley
2009-12-10 20:39                             ` Russell King
2009-12-10 19:42                         ` Ilya Loginov
2009-12-10 19:43                           ` Russell King
2009-12-10 19:48                             ` Ilya Loginov
2009-12-10 19:46                 ` Ilya Loginov
2009-12-10 20:28                   ` James Bottomley
2009-12-10 20:41                     ` Ilya Loginov
2009-12-10 20:48                     ` Ilya Loginov
2009-12-10 20:59                       ` James Bottomley
2009-12-10 21:27                         ` Ilya Loginov
2009-12-10 21:43                           ` Ilya Loginov
2009-12-10 22:00                           ` James Bottomley
2009-12-10 22:03                             ` David Miller
2009-12-10 22:33                             ` Ilya Loginov

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=1260400273.14369.52.camel@mulgrave.site \
    --to=james.bottomley@hansenpartnership.com \
    --cc=isloginov@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-arch@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 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).