From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kallol Biswas <Kallol_Biswas@pmc-sierra.com>
Cc: linuxppc-dev@ozlabs.org
Subject: RE: memory with __get_free_pages and disabling caching
Date: Sat, 25 Mar 2006 11:20:34 +1100 [thread overview]
Message-ID: <1143246035.3710.29.camel@localhost.localdomain> (raw)
In-Reply-To: <478F19F21671F04298A2116393EEC3D50A9C8D@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
On Fri, 2006-03-24 at 15:44 -0800, Kallol Biswas wrote:
> Thank you.
>
> I wonder how consistent ptes are used if all kernel memory is mapped with large tlb.
> In the __dma_alloc_coherent() routine pages are allocated with alloc_pages(), new virtual address is created in consistent region,
> then consistent ptes are populated. Looks like that the routine creates a new virtual mapping. The memory is addressed with the new address.
>
> Do we have two mappings in the TLB for the same physical address?
Yes, it seems like we do... the consistent DMA stuff assumes that is
safe to do, which is not the case on 6xx CPUs but might be on 4xx.
> When I find it out, I will do a posting.
>
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Friday, March 24, 2006 2:31 PM
> To: Kallol Biswas
> Cc: linuxppc-dev@ozlabs.org
> Subject: RE: memory with __get_free_pages and disabling caching
>
> On Fri, 2006-03-24 at 11:13 -0800, Kallol Biswas wrote:
> > We have a little endian device on a PPC 440GX based system.
> > The descriptors need to be swapped. With E bit turned on we can save swapping time.
> >
> > May be all the pages with _get_free_page already are mapped with large tlb entry.
> >
> > How about making a window (ptes) like consistent memory?
>
> If you allocate with consistent allocator on 4xx, you should be able to hack the PTEs to set the E bit, but I think it's not necessary. We've been swapping descriptor for ages without any noticeable performance loss since pretty much all network devices have little endian descriptor rings :) Look into using the {ld,st}_le{16,32} inlines, they use the native swapped load/store instructions of the CPU to store things in little endian format. They shouldn't cost more or at least not significantly more than normal load/stores.
>
> Ben.
>
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > Sent: Thursday, March 23, 2006 7:06 PM
> > To: Kallol Biswas
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: Re: memory with __get_free_pages and disabling caching
> >
> > On Thu, 2006-03-23 at 18:15 -0800, Kallol Biswas wrote:
> > > Hello,
> > > Is there an easy way to set page table attributes for the
> > > memory returned by __get_free_pages()?
> > >
> > > I need to be able to turn off caching and turn on E bit for these
> > > pages.
> >
> > The Evil bit ? heh ! what are you trying to do ? here ... you can always create a virtual mapping to those pages with different attributes but that's nor recommended as some processors will shoke pretty badly if you end up with both cacheable and non-cacheable mappings for the same page.
> > However, it's not always possible to unmap the initial mapping since it's common to use things like large pages, BATs, large TLB entries etc... to map kernel memory..
> >
> > > I tried to walk through the page tables data structures to get the
> > > pte, but it seems that the pmd is not present for the pages. If
> > > someone has done investigation on this before please send me a reply.
> > >
> > Kernel linear memory isn't necessarily mapped by the page tables. What are you trying to do and with what processor ?
> >
> >
> >
> > Ben.
> >
next prev parent reply other threads:[~2006-03-25 0:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-24 23:44 memory with __get_free_pages and disabling caching Kallol Biswas
2006-03-25 0:20 ` Benjamin Herrenschmidt [this message]
2006-03-25 0:29 ` Matt Porter
2006-03-25 0:27 ` Matt Porter
2006-03-25 1:02 ` Benjamin Herrenschmidt
2006-03-25 1:25 ` Matt Porter
-- strict thread matches above, loose matches on Subject: below --
2006-03-24 19:13 Kallol Biswas
2006-03-24 19:29 ` Kumar Gala
2006-03-24 22:17 ` Paul Mackerras
2006-03-24 22:30 ` Benjamin Herrenschmidt
2006-03-24 2:15 Kallol Biswas
2006-03-24 3:05 ` Benjamin Herrenschmidt
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=1143246035.3710.29.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=Kallol_Biswas@pmc-sierra.com \
--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).