All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <glisse@freedesktop.org>
To: "Thomas Hellström" <thomas@shipmail.org>
Cc: Dave Airlie <airlied@gmail.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.sf.net
Subject: Re: TTM page pool allocator
Date: Wed, 22 Jul 2009 14:12:42 +0200	[thread overview]
Message-ID: <1248264762.2336.1.camel@localhost> (raw)
In-Reply-To: <4A66CD54.6070104@shipmail.org>

On Wed, 2009-07-22 at 10:27 +0200, Thomas Hellström wrote:
> Jerome Glisse wrote:
> > On Thu, 2009-06-25 at 17:53 +0200, Thomas Hellström wrote:
> >   
> >> Jerome Glisse skrev:
> >>     
> >>> Hi,
> >>>
> >>> Thomas i attach a reworked page pool allocator based on Dave works,
> >>> this one should be ok with ttm cache status tracking. It definitely
> >>> helps on AGP system, now the bottleneck is in mesa vertex's dma
> >>> allocation.
> >>>
> >>> Cheers,
> >>> Jerome
> >>>   
> >>>       
> >> Hi, Jerome!
> >> In general it looks very good. Some things that need fixing:
> >>
> >> 1)  We must have a way to hand back pages. I still not quite understand 
> >> how the shrink callbacks work and whether they are applicable. Another 
> >> scheme would be to free, say 1MB when we have at least 2MB available.
> >>
> >> 2) We should avoid including AGP headers if AGP is not configured. 
> >> Either reimplement unmap_page_from_agp or map_page_into_agp or move them 
> >> out from the AGP headers. We've hade complaints before from people with 
> >> AGP free systems that the code doesn't compile.
> >>
> >> 3) Since we're allocating (and freeing) in batches we should use the 
> >> set_pages_array() interface to avoid a global tlb flush per page.
> >>
> >> 4) We could now skip the ttm_tt_populate() in ttm_tt_set_caching, since 
> >> it will always allocate cached pages and then transition them.
> >>
> >>     
> >
> > Okay 4) is bad, what happens (my brain is a bit meltdown so i might be
> > wrong) :
> > 1 - bo get allocated tt->state = unpopulated
> > 2 - bo is mapped few page are faulted tt->state = unpopulated
> > 3 - bo is cache transitioned but tt->state == unpopulated but
> >     they are page which have been touch by the cpu so we need
> >     to clflush them and transition them, 
> 
> Right.
> 
> > this never happen if
> >     we don't call ttm_tt_populate and proceed with the remaining
> >     of the cache transitioning functions
> >   
> 
> Why can't we just skip ttm_tt_populate and proceed with the remaining of 
> the cache transitioning functions? Then all pages currently allocated to 
> the TTM will be transitioned.
> 

Because not all tt->pages entry have valid page some are null and thus
we have to go through the whole table and transition page per page. I
did that and quick benchmark showed that it's faster to fully populate
and fully transition.

Cheers,
Jerome


  reply	other threads:[~2009-07-22 12:14 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-25 12:01 TTM page pool allocator Jerome Glisse
2009-06-25 15:53 ` Thomas Hellström
2009-07-21 17:34   ` Jerome Glisse
2009-07-21 18:00     ` Jerome Glisse
2009-07-21 19:22       ` Jerome Glisse
2009-07-22  8:37         ` Thomas Hellström
2009-07-28 16:48           ` ttm_mem_global Jerome Glisse
2009-07-28 18:55             ` ttm_mem_global Thomas Hellström
2009-07-29  8:59               ` ttm_mem_global Jerome Glisse
2009-07-29  9:39                 ` ttm_mem_global Thomas Hellström
2009-07-29 13:04                   ` ttm_mem_global Jerome Glisse
2009-07-22 13:16         ` TTM page pool allocator Michel Dänzer
2009-07-22 13:31           ` Jerome Glisse
2009-07-22 19:13             ` Thomas Hellström
2009-07-22 22:35               ` Jerome Glisse
2009-07-22 23:24                 ` Keith Whitwell
2009-07-22 23:27                   ` Dave Airlie
2009-07-22  8:27     ` Thomas Hellström
2009-07-22 12:12       ` Jerome Glisse [this message]
2009-07-22 19:10         ` Thomas Hellström
2009-06-26  0:00 ` Dave Airlie
2009-06-26  6:31   ` Thomas Hellström
2009-06-26  7:33     ` Jerome Glisse
2009-06-26  7:31   ` Jerome Glisse
2009-06-26  7:38     ` Dave Airlie
2009-06-26 13:59   ` Jerome Glisse
2009-06-29 21:12     ` Thomas Hellström
2009-07-09  6:06       ` Dave Airlie
2009-07-09  8:48         ` Michel Dänzer

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=1248264762.2336.1.camel@localhost \
    --to=glisse@freedesktop.org \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.sf.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas@shipmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.