From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Dmitry Torokhov <dtor@chromium.org>
Cc: Christophe Ricard <christophe.ricard@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
tpmdd-devel@lists.sourceforge.net
Subject: Re: [tpmdd-devel] [PATCH] tpm: fix cacheline alignment for DMA-able buffers
Date: Tue, 9 Aug 2016 18:01:14 +0300 [thread overview]
Message-ID: <20160809150114.GA9672@intel.com> (raw)
In-Reply-To: <20160809094610.GA13566@intel.com>
On Tue, Aug 09, 2016 at 12:46:10PM +0300, Jarkko Sakkinen wrote:
> On Fri, Jul 29, 2016 at 10:30:22AM -0700, Dmitry Torokhov wrote:
> > On Fri, Jul 29, 2016 at 10:27 AM, Jason Gunthorpe
> > <jgunthorpe@obsidianresearch.com> wrote:
> >
> > On Thu, Jul 28, 2016 at 07:59:13PM -0700, Andrey Pronin wrote:
> > > Annotate buffers used in spi transactions as ____cacheline_aligned
> > > to use in DMA transfers.
> > >
> > > Signed-off-by: Andrey Pronin <apronin@chromium.org>
> > >Â drivers/char/tpm/st33zp24/spi.c | 4 ++--
> > > drivers/char/tpm/tpm_tis_spi.c | 4 ++--
> > >Â 2 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/st33zp24/spi.c
> > b/drivers/char/tpm/st33zp24/spi.c
> > > index 9f5a011..0e9aad9 100644
> > > +++ b/drivers/char/tpm/st33zp24/spi.c
> > > @@ -70,8 +70,8 @@
> > >Â struct st33zp24_spi_phy {
> > >Â Â Â Â struct spi_device *spi_device;
> > >
> > > -Â Â Â u8 tx_buf[ST33ZP24_SPI_BUFFER_SIZE];
> > > -Â Â Â u8 rx_buf[ST33ZP24_SPI_BUFFER_SIZE];
> > > +Â Â Â u8 tx_buf[ST33ZP24_SPI_BUFFER_SIZE] ____cacheline_aligned;
> > > +Â Â Â u8 rx_buf[ST33ZP24_SPI_BUFFER_SIZE] ____cacheline_aligned;
> > >
> > >Â Â Â Â int io_lpcpd;
> > >Â Â Â Â int latency;
> >
> > Hurm, this still looks wrong to me. Aligning the start of buffers is
> > not enough, the DMA'able space must also end on a cache line as well.
> >
> > So, the buffers must also always be placed at the end of the struct.
> >
> > IMHO It would be cleaner and safer to always kmalloc the DMA buffer
> > alone than to try and optimize like this.
> >
> > In this case moving them to the end of the structure and commenting why
> > they have to be at the end might be less invasive change. More
> > performance-efficient and resilient in low memory situations too.
>
> kmallocs would be done in the driver initialization:
>
> * you rarely are in low memory situation
> * performance gain/loss is insignificant
>
> I really don't see your point.
I'm fine having them at the end of the structure mainly for simplicity
reasons but those arguments just didn't hold at all.
/Jarkko
next prev parent reply other threads:[~2016-08-09 15:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-29 2:59 [PATCH] tpm: fix cacheline alignment for DMA-able buffers Andrey Pronin
2016-07-29 17:27 ` Jason Gunthorpe
[not found] ` <20160729172702.GB7020-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-07-29 17:30 ` Dmitry Torokhov
2016-08-09 9:46 ` Jarkko Sakkinen
2016-08-09 15:01 ` Jarkko Sakkinen [this message]
[not found] ` <20160809150114.GA9672-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-08-09 15:18 ` Dmitry Torokhov
2016-08-09 22:08 ` [tpmdd-devel] " Jason Gunthorpe
[not found] ` <CAE_wzQ95LAm7JkfB=V2VZVc4Vha4GcRyOBH_J8ZEh1gG+ZjEAA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-08-10 10:36 ` Jarkko Sakkinen
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=20160809150114.GA9672@intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=christophe.ricard@gmail.com \
--cc=dtor@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tpmdd-devel@lists.sourceforge.net \
/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).