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/
next prev parent 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).