linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Tejun Heo <htejun@gmail.com>, Jens Axboe <axboe@suse.de>,
	James Bottomley <James.Bottomley@SteelEye.com>,
	Dave Miller <davem@redhat.com>,
	bzolnier@gmail.com, james.steward@dynamicratings.com,
	jgarzik@pobox.com, mattjreimer@gmail.com,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCHSET] block: fix PIO cache coherency bug, take 2
Date: Sun, 4 Jun 2006 23:23:48 +0100	[thread overview]
Message-ID: <20060604222347.GG4484@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20060604204444.GF4484@flint.arm.linux.org.uk>

On Sun, Jun 04, 2006 at 09:44:44PM +0100, Russell King wrote:
> On Sun, Jun 04, 2006 at 12:41:19PM +0900, Tejun Heo wrote:
> > Russell, can you please verify arm's flush_kernel_dcache_page()?
> 
> That should be fine from a theoretical standpoint

I'll add to this statement that the cache flushing on ARM is only
ever required when the page ends up in userspace - if we're reading
a page into the page cache to throw it out via NFS or sendfile then
the cache flush is a complete waste of time.

Why is this?  Well, if the data has been written to the kernel mapping
by the CPU, it may be contained in the cache lines corresponding to
that mapping.  When that memory is passed to a network interface to
send, the network interface either reads data from the kernel mapping
via PIO (in which case it reads the data from the cache), or it
performs DMA.  In the case of DMA, the DMA API handles the cache
coherency issues with respect to dirty data in the kernel mapping.

Moreover, there's the problem of read-ahead.  When data is read from
a block device, more data than that which is required is usually read
in case it's required a short time later.  If the data is not required,
it is thrown away during an eviction cycle.  However, any cache flushing
that you've performed for uses "other than kernel space" is then a waste
of resources - the only time that such handling is needed is when the
data is actually used for these other uses - which in the case of ARM
means userspace.

Given the above, I believe that the method being proposed will be
_far_ too expensive, maybe to the point where (eg) disabling read-
ahead _entirely_ on ARM makes the system overall more efficient.

In this respect, I continue to believe that the way ARM (in principle)
does flush_dcache_page() is what is required here - if the page has
not been mapped into userspace, it merely marks the page as containing
dirty cache lines, and the resulting cache maintainence will only
happen when (and if) the page really does get mapped into userspace.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

  reply	other threads:[~2006-06-04 22:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-04  3:41 [PATCHSET] block: fix PIO cache coherency bug, take 2 Tejun Heo
2006-06-04  3:41 ` [PATCH 1/5] arm: implement flush_kernel_dcache_page() Tejun Heo
2006-06-04  3:49   ` [PATCH 1/5] (REPOST) " Tejun Heo
2006-06-04  6:45   ` [PATCH 1/5] " David Miller
2006-06-04  6:53     ` Tejun Heo
2006-06-04  7:04       ` David Miller
2006-06-04  3:41 ` [PATCH 5/5] md: add cpu cache flushes after kmapping and modifying a page Tejun Heo
2006-06-04  3:41 ` [PATCH 4/5] SCSI: " Tejun Heo
2006-06-04  8:20   ` Christoph Hellwig
2006-06-04  9:13     ` Tejun Heo
2006-06-04 20:24       ` Guennadi Liakhovetski
2006-06-04  3:41 ` [PATCH 2/5] ide: " Tejun Heo
2006-06-04  8:17   ` Christoph Hellwig
2006-06-04  9:09     ` Tejun Heo
2006-06-04  3:41 ` [PATCH 3/5] libata: " Tejun Heo
2006-06-04 20:44 ` [PATCHSET] block: fix PIO cache coherency bug, take 2 Russell King
2006-06-04 22:23   ` Russell King [this message]
2006-06-05 14:27     ` James Bottomley
2006-06-05 14:44       ` Russell King
2006-06-05 15:24         ` James Bottomley
2006-06-05 15:34           ` Russell King
2006-06-05 15:47             ` James Bottomley
2006-06-05 15:48               ` Russell King
2006-06-05 16:16                 ` James Bottomley
2006-06-05 16:37                   ` Russell King
2006-06-05 13:43   ` James Bottomley
2006-06-06 11:00     ` Miklos Szeredi

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=20060604222347.GG4484@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=James.Bottomley@SteelEye.com \
    --cc=axboe@suse.de \
    --cc=bzolnier@gmail.com \
    --cc=davem@redhat.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=htejun@gmail.com \
    --cc=james.steward@dynamicratings.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mattjreimer@gmail.com \
    /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).