linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dan Malek <dan@embeddededge.com>
To: David Blythe <blythe@broadon.com>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: [RFC] consistent_sync and non L1 cache line aligned buffers
Date: Tue, 15 Jul 2003 18:15:11 -0400	[thread overview]
Message-ID: <3F147CEF.3030803@embeddededge.com> (raw)
In-Reply-To: 3F14719F.7080105@broadon.com


David Blythe wrote:

> 2) change the definition to allow non-aligned addresses and handle them
> gracefully

What's your implementation proposal?  I contend you can't guarantee
a perfectly working solution due to the race conditions surrounding
the software managment of a cache line, the processor potentially
accessing that cache line, and the DMA that is in progress.  In any
case, you are going to require the programmer has knowledge of something
associated with the cache line, either the alignment or other processor
accessed data that will reside there.  Although the DMA buffers on
the stack are a very poor programming practice, the main problem for
us is that it immediately shows the programmer requires proper buffer
alignment or assignment of other objects to the cache line that won't
cause problems.  If you aligned those stack DMA buffers, you wouldn't
see this problem.

A design constraint of non-coherent cache is the operations on the
cache lines are whole and atomic.  IMHO, the easiest solution is
alignment of buffers.....plus it's likely to be a performance improvement.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2003-07-15 22:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <F0B628F30F48064289D8CCC1EE21B7A80C48A5@mvebe001.americas.n okia.com>
2003-07-15 20:39 ` [RFC] consistent_sync and non L1 cache line aligned buffers Eugene Surovegin
2003-07-15 21:26   ` David Blythe
2003-07-15 22:15     ` Dan Malek [this message]
2003-07-16  0:12 Darin.Johnson
  -- strict thread matches above, loose matches on Subject: below --
2003-07-15 23:04 Darin.Johnson
2003-07-15 23:34 ` Paul Mackerras
2003-07-15 23:50   ` Eugene Surovegin
2003-07-15 23:45 ` Matt Porter
2003-07-16 14:01 ` Dan Malek
2003-07-15 20:47 Darin.Johnson
2003-07-15 20:18 Darin.Johnson
2003-07-15  4:32 Eugene Surovegin
2003-07-15 15:46 ` Tom Rini
2003-07-15 16:20   ` Eugene Surovegin
2003-07-15 16:25     ` Tom Rini
2003-07-15 16:17 ` Matt Porter
2003-07-15 16:27   ` Eugene Surovegin
2003-07-15 23:51     ` Matt Porter

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=3F147CEF.3030803@embeddededge.com \
    --to=dan@embeddededge.com \
    --cc=blythe@broadon.com \
    --cc=linuxppc-embedded@lists.linuxppc.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 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).