From: Ilya Loginov <isloginov@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Woodhouse <dwmw2@infradead.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 02:11:28 +0300 [thread overview]
Message-ID: <20091122021128.db47e202.isloginov@gmail.com> (raw)
In-Reply-To: <20091121095429.1378828c.akpm@linux-foundation.org>
> The one somewhat fragile thing is that we'll end up in a situation
> where an architecture could implement a real flush_dcache_page(), but
> would forget to set SOMETHING_LIKE_CONFIG_CPU_HAS_DCACHE_ALIAS. Or
> vice versa. To make things reliable it would be good to cause a
> compilation failure in that case.
Yes, I do understand this.
> One way of addressing this is to
>
> - change every arch/*/include/asm/cacheflush.h to include
> asm-generic/cacheflush.h
>
> - put #ifndef SOMETHING_LIKE_CONFIG_CPU_HAS_DCACHE_ALIAS wrappers
> around all content in asm-generic/cacheflush
>
> So it the above mistake happens, we'll get lots of duplicated
> definitions, or no definitions at all (I think).
Actually I don't think that it is the best solution. Let me explain.
1) The problem is that flush_dcache_page is defined for a bunch of
different architectures. (x86, ia64, etc). But in most of the cases
flush_dcache_page is empty, but should be defined anyway. Just see the
review:
h8300 -- empty. All cache defines like asm-generic, but worse
(without do {} while(0)).
blackfin -- empty for architectures which do not define
CONFIG_BFIN_EXTMEM_WRITEBACK or CONFIG_BFIN_L2_WRITEBACK.
frv
x86 -- empty. All cache defines like asm-generic, but it was
implemented throught inline.
ia64
sh -- in case if ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE was defined
most flash operations are empty, but there no this define anywhere in
kernel.
alpha -- empty, like most cache operations.
avr32 -- empty. But many other operations are defined.
arm
sparc
powerpc
m32r -- empty for all chips, like most kernel operations.
microblaze -- empty.
cris -- empty. cacheflush is equal to asm-generic, except
define change_page_attr function.
s390 -- empty. cacheflush is equal to asm-generic, except
define kernel_map_pages function if CONFIG_DEBUG_PAGEALLOC was defined.
mips -- different for different boards and architectures.
parisc
mn10300 -- empty. But there are functions like
mn10300_dcache_flush_page. I think this is bad.
m68k -- empty if __uClinux__ is using.
xtensa -- empty if DCACHE_WAY_SIZE < PAGE_SIZE
So you see, it is a real mess. Only in 8 of 20 architectures
this call don't empty!
2) In the asm-generic/cacheflush.h also was defined a lot of functions
that could have a conflict and we don't want to have this conflict
anyway. So we will meet here the same problem that was described in you
letter:
> we'll get lots of duplicated
> definitions, or no definitions at all
3) I want to mention that flush_dcache_page depends on the type of
process and chipset as well, so in order to make such things workable
developers usually set different flags in Kconfig. For example
SYS_HAS_EARLY_PRINTK or DMA_NONCOHERENT. And this is the most effective
way of doing this, as far as I see this.
I've just checked most of the places in the kernel where
flush_dcache_page is used. See the summary:
1)
drivers/staging/rspiusb/rspiusb.c
for (i = 0; i < pdx->maplist_numPagesMapped[frameInfo]; i++)
flush_dcache_page(maplist_p[i]);
2)(is equal to 3))
fs/reiserfs/super.c
fs/reiserfs/inode.c
fs/ufs/super.c
fs/ext2/super.c
fs/nilfs2/mdt.c
fs/jfs/super.c
fs/ocfs2/quota_global.c
fs/ext3/super.c
fs/ext4/super.c
This operation is executed into a loop (big enought).
flush_dcache_page(bh->b_page);
3)
in all other cases there is
flush_dcache_page(page);
4)*
fs/bio.c
mm/bounce.c
net/sunrpc/xprtrdma/rpc_rdma.c
These files call flush_dcache_page in bio_for_each_segment. But
there are another work. So we have no pointless empty loops.
I think we should select SYS_HAS_FLUSH_DCACHE_PAGE for those
architectures which requires it(to fix the bug) (and implement empty
flush_dcache_page throught inline like in x86(to avoid pointless do
{} while(0))).
What do you think about this?
--
Ilya Loginov <isloginov@gmail.com>
next prev parent reply other threads:[~2009-11-21 23:11 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 [this message]
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
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=20091122021128.db47e202.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 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.