All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pauli Nieminen <suokkos@gmail.com>
To: "Thomas Hellström" <thomas@shipmail.org>
Cc: "Michel Dänzer" <michel@daenzer.net>,
	dri-devel@lists.sourceforge.net,
	"Jerome Glisse" <jglisse@redhat.com>
Subject: Re: [RFC] drm/ttm: add pool wc/uc page allocator
Date: Wed, 3 Mar 2010 14:13:55 +0200	[thread overview]
Message-ID: <548cdfc21003030413h9594bb1hb543d998844fdd1e@mail.gmail.com> (raw)
In-Reply-To: <4B8CFB1B.1020806@shipmail.org>

2010/3/2 Thomas Hellström <thomas@shipmail.org>:
> Michel Dänzer wrote:
>>
>> On Tue, 2010-03-02 at 00:32 +0200, Pauli Nieminen wrote:
>>>
>>> bo allocation is still too expensive operation for dma buffers in
>>> classic mesa. It takes quite a lot cpu time in bind memory (agp
>>> system) and ttm_mem_global functions. Would it be possible to move
>>> some parts those expensive operations into pool fill and pool free
>>> code?
>>>
>>
>> Maybe we need userspace BO sub-allocation and/or caching. At least for
>> the 'DMA' buffers it should be simple for userspace to keep a round
>> robin list of buffers.
>>
>>
>>
>
> Yeah, that's indeed one of the solutions.
> Drawback is that there is no way for process 2 to empty process 1's bo cache
> in situations of memory shortage, although I guess there are ways to send
> "empty cache" events to user-space if needed.
>
> The other solution is kernel bo sub-allocation and caching, but then one has
> to live with the overhead of page-faults and vma setups / teardowns with
> associated tlb flushes.
>
> /Thomas

There is already round-robin list of (suballocated) buffers and that
works well enough. Only problem with current implementation is that
freeing of buffers is done very lazily to avoid any need for
reallocation. But extra memory use from GTT looks small price to pay
for avoiding cost of allocating bos.

When I tested to reduce number of buffers held by mesa I was hoping to
lose very little performance to reduce number of empty buffers held by
mesa. But that was a bit too much hoped for.

But at least this looks like enough for others components reallocating
buffers often. There is temporary bo allocations in ddx. Kernel pool
allocation reduces allocation cost enough to match what cost was in
UMS. That means 20-40 times better allocation performance for uc/wc
pages.

Pauli

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

  parent reply	other threads:[~2010-03-03 12:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-28 21:30 [RFC] drm/ttm: add pool wc/uc page allocator Pauli Nieminen
2010-03-01 22:32 ` Pauli Nieminen
2010-03-02 10:56   ` Michel Dänzer
     [not found]     ` <4B8CFB1B.1020806@shipmail.org>
2010-03-03 12:13       ` Pauli Nieminen [this message]
2010-03-03 12:47         ` Luca Barbieri
2010-03-03 13:23           ` Thomas Hellstrom
2010-03-03 14:03             ` Luca Barbieri
2010-03-03 14:19               ` Thomas Hellstrom
2010-03-03 13:33   ` Jerome Glisse
2010-03-03 14:23     ` Pauli Nieminen
2010-03-03 14:50       ` Jerome Glisse
2010-03-03 15:46         ` Pauli Nieminen
2010-03-03 16:02           ` Jerome Glisse

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=548cdfc21003030413h9594bb1hb543d998844fdd1e@mail.gmail.com \
    --to=suokkos@gmail.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=jglisse@redhat.com \
    --cc=michel@daenzer.net \
    --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.