From: Jerome Glisse <glisse@freedesktop.org>
To: "Thomas Hellström" <thomas@shipmail.org>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.sf.net
Subject: Re: TTM page pool allocator
Date: Tue, 21 Jul 2009 20:00:31 +0200 [thread overview]
Message-ID: <1248199231.2368.17.camel@localhost> (raw)
In-Reply-To: <1248197676.2368.11.camel@localhost>
On Tue, 2009-07-21 at 19:34 +0200, Jerome Glisse wrote:
> On Thu, 2009-06-25 at 17:53 +0200, Thomas Hellström wrote:
> >
> > 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, this never happen if
> we don't call ttm_tt_populate and proceed with the remaining
> of the cache transitioning functions
>
> As a workaround i will try to go through the pages tables and
> transition existing pages. Do you have any idea for a better
> plan ?
>
> Cheers,
> Jerome
My workaround ruin the whole idea of pool allocation what happens
is that most bo get cache transition page per page. My thinking
is that we should do the following:
- is there is a least one page allocated then fully populate
the object and do cache transition on all the pages.
- otherwise update caching_state and leaves object unpopulated
This needs that we some how reflect the fact that there is at least
one page allocated, i am thinking to adding a new state for that :
ttm_partialy_populated
Thomas what do you think about that ?
Cheers,
Jerome
next prev parent reply other threads:[~2009-07-21 18:01 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 [this message]
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
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=1248199231.2368.17.camel@localhost \
--to=glisse@freedesktop.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox