From: Ilya Loginov <isloginov@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.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: Thu, 10 Dec 2009 02:36:09 +0300 [thread overview]
Message-ID: <20091210023609.b8c9bd34.isloginov@gmail.com> (raw)
In-Reply-To: <1260400273.14369.52.camel@mulgrave.site>
On Wed, 09 Dec 2009 17:11:13 -0600
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
Sorry. But I didn't understand again. You wrote:
> > > 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 think that do_blktrans_request is calling for request and that every page in
request flushes exactly once.
> > > 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.
But the flush_kernel_dcache_page() call exists only for sh and parisc. For
other architectures this call is empty. So, we will not fix the bug if we
call flush_kernel_dcache_page().
But. I could do that rq_flush_dcache_pages will call flush_kernel_dcache_page
for architectures where ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE was defined.
--
Ilya Loginov <isloginov@gmail.com>
next prev parent reply other threads:[~2009-12-09 23:36 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
2009-12-09 23:36 ` Ilya Loginov [this message]
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=20091210023609.b8c9bd34.isloginov@gmail.com \
--to=isloginov@gmail.com \
--cc=James.Bottomley@HansenPartnership.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 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.