public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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>

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox