linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Remi Machet <rmachet@slac.stanford.edu>
To: benh@kernel.crashing.org
Cc: Linux PPC <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH 1/3] powerpc: dma code cleanup
Date: Tue, 07 Oct 2008 15:11:27 -0700	[thread overview]
Message-ID: <1223417488.17585.46.camel@pcds-ts102.slac.stanford.edu> (raw)
In-Reply-To: <1223414534.8157.63.camel@pasglop>

On Wed, 2008-10-08 at 08:22 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2008-10-07 at 14:05 -0700, Remi Machet wrote:
> > +       /*
> > +        * Mark the pages as Reserved: this memory is used by a DMA
> > engine,
> > +        * it cannot be swapped.
> > +        * Also mark each page as un-cached. We ass ume here that a
> > PTE
> > +        * already exist (valid assumption for the DMA Zone)
> > +        */
> > +       for (addr = kaddr, p = page; addr < kaddr+size;
> > +                       addr += PAGE_SIZE, p++) {
> > +               pte_t *pte;
> > +               spinlock_t *ptl;
> > +
> > +               SetPageReserved(p);
> > +               pte = get_locked_pte(&init_mm, addr, &ptl);
> > +               set_pte_at(&init_mm, addr,
> > +                       pte, mk_pte(p,
> > pgprot_noncached(PAGE_KERNEL)));
> > +               pte_unmap_unlock(pte, ptl);
> > +       }
> > +       flush_tlb_kernel_range(kaddr, kaddr+size-1);
> > +
> 
> There are a few problems with the above approach:
> 
>  - Avoid SetPageReserved. It's not useful. Kernel memory doesn't
> get swapped, and if you happen to map it into userspace, it's up
> to that mapping to have the right attributes to prevent that.
> 
>  - Setting the PTE to non-cached will not work for a whole bunch of
> things. The kernel linear mapping is often mapped using large bolted TLB
> entries. For example, on 44x, if you page is in the bottom 768M, it will
> be mapped using a bolted 256M cacheable TLB entry and you may not even
> have a PTE for it. kmap will not help
Yes I see the problem. I will try to rewrite that part using the vmalloc
pool.

> 
>  - You are potentially creating a lot of permanently kmap'ed memory. But
> the kmap pool might get exhausted... bad.
This will disappear since I am going to use the vmalloc pool but out of
curiosity: calling kmap should not result in any virtual memory from the
kmap pool being used unless the allocated page is in high memory. Do you
expect many driver to call dma_alloc with GFP_HIGHMEM?

Thanks!

Remi

  reply	other threads:[~2008-10-07 22:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 21:05 [PATCH 1/3] powerpc: dma code cleanup Remi Machet
2008-10-07 21:22 ` Benjamin Herrenschmidt
2008-10-07 22:11   ` Remi Machet [this message]
2008-10-07 22:12     ` Benjamin Herrenschmidt
2008-10-09 17:41   ` Remi Machet

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=1223417488.17585.46.camel@pcds-ts102.slac.stanford.edu \
    --to=rmachet@slac.stanford.edu \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.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).