From: Ilya Loginov <isloginov@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Peter Horton <phorton@bitbox.co.uk>,
"Ed L. Cashin" <ecashin@coraid.com>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [PATCH] mtd: fix mtd_blkdevs problem with caches on some architectures (2.6.31)
Date: Sun, 22 Nov 2009 21:49:49 +0300 [thread overview]
Message-ID: <20091122214949.e1ffa058.isloginov@gmail.com> (raw)
In-Reply-To: <1258883630.1127.45.camel@macbook.infradead.org>
On Sun, 22 Nov 2009 09:53:50 +0000
David Woodhouse <dwmw2@infradead.org> wrote:
> The thing is, having a function called flush_dcache_page() which doesn't
> actually flush a page of the dcache is just blatantly stupid.
Unfortunately, it's well-established that all architectures have these
functions. Many kernel systems, for example file systems drivers (ext2,
ext3, ntfs), use them.
In letter to Andrew Morton I wrote that among 20 architectures this call
is not empty only for 8 of them. And it is the problem.
But some architectures really need this call. And kernel has to work
reasonably with them too. Therefore it is required often to call for
empty functions.
> It's misnamed -- it should probably be called something like
> 'flush_valiased_dcache_page()' or 'unalias_dcache_page()' instead, since
> I believe it's only supposed to cope with aliasing issues with virtually
> indexed caches.
I don't think so. For example I had this bug on the processor, which
icache don't finds for data in dcache. There was no dcache aliases.
> If you're talking about _extending_ the existing silly name to a new
> ARCH_IMPLEMENTS_FOO macro or Kconfig option, perhaps this would be a
> good time to fix the nomenclature, rather than propagating the error?
Andrew has showed me in his first letter another topic in this mailing.
It is said there that there is no reasonable infrastructure in kernel to
correct such things. The first patch can fix bug in the mtd but the
problem of useless cycle on many architectures is arising.
It is because there is nothing associated with the flush_dcache_page()
function.
This way enable us to solve and this problem too. But I agree that it
is not elegant. Have you any idea how to make it better?
Thanks!
--
Ilya Loginov <isloginov@gmail.com>
next prev parent reply other threads:[~2009-11-22 18:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-18 14:08 [PATCH] mtd: fix mtd_blkdevs problem with caches on some architectures (2.6.31) Ilya Loginov
2009-11-21 0:37 ` Andrew Morton
2009-11-21 14:04 ` Ilya Loginov
2009-11-21 17:54 ` Andrew Morton
2009-11-21 23:11 ` Ilya Loginov
2009-11-21 23:26 ` Andrew Morton
2009-11-21 23:36 ` Ilya Loginov
2009-11-22 9:46 ` Ilya Loginov
2009-11-22 9:53 ` David Woodhouse
2009-11-22 18:49 ` Ilya Loginov [this message]
2009-11-22 13:29 ` Ingo Molnar
2009-11-22 13:55 ` Ilya Loginov
2009-11-22 18:48 ` Andrew Morton
2009-11-22 19:18 ` Ilya Loginov
2009-11-22 19:51 ` Andrew Morton
2009-11-22 20:55 ` Ilya Loginov
2009-11-24 20:48 ` Andrew Morton
2009-11-25 1:01 ` 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=20091122214949.e1ffa058.isloginov@gmail.com \
--to=isloginov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dwmw2@infradead.org \
--cc=ecashin@coraid.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=phorton@bitbox.co.uk \
/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