From: "Thomas Hellström" <thellstrom@vmware.com>
To: "suresh.b.siddha@intel.com" <suresh.b.siddha@intel.com>
Cc: Ingo Molnar <mingo@elte.hu>, Dave Airlie <airlied@linux.ie>,
Arjan van de Ven <arjan@infradead.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"dri-devel@lists.sourceforge.net"
<dri-devel@lists.sourceforge.net>
Subject: CPA interfaces WAS x86: Fix CPA memtype reserving in the set_pages_array cases
Date: Mon, 03 Aug 2009 21:31:50 +0200 [thread overview]
Message-ID: <4A773B26.20007@vmware.com> (raw)
In-Reply-To: <1249318705.27006.10777.camel@localhost.localdomain>
Suresh Siddha skrev:
>
> Also, now that we have set_pages_array interface, do we still need the
> set_memory_array_uc interface? Removing that should clean up the cpa
> code a bit.
>
> thanks,
> suresh
>
>
This might be a good time to discuss how graphics drivers will use this
interface in the not too distant future. These are my thoughts.
1) A pool of uc / wc pages: Jerome Glisse and Dave Airlie have been
working on this. It will hugely speed up the allocation and freeing of
transient uc / wc buffers. Pages will be allocated and freed in chunks
of a couple of megabytes, and caching attributes are changed using the
set_pages_array() interface. The pool will sit in the TTM driver.
1a) Using large pages: With such a pool it would be beneficial to
allocate and free large pages to avoid page splitting in the CPA code.
There is no code in the pool implementation for that yet, but I think
the set_memory_array_xx will be the best interface for that, although I
guess set_pages_array_xx would work.
2) Optimize cache flushing:
2a) I think both the TTM code and AGP code flushes the cache before
changing from wb, to make sure the device sees the data. Therefore with
these callers, I don't think the CPA code needs to flush the cache
again, and it might be beneficial with a "cache_already_flushed" bool to
some of the function apis.
2b) Use self-snooping where available regardless of the value of the
"cache_already_flushed" bool.
3) set_pages_array_np():
This is a bit controversial, but will enable a certain valuable class of
graphics optimizations. The idea is to, instead of marking the PTEs as
wc or uc, marking them as non-present, np. This means that the TTM code
does not need to bother with CPA if it wants to make quick cached reads
from graphics buffers. Just use kmap_atomic() and make sure to clflush
before unmap.
The caveat is that all np pages must be marked wb before hibernation
since the hibernation code will try to read from the linear kernel map.
But we have to deal with that today for uc / wc highmem pages today as
well since the hibernation code will try to kmap() them with wb page
attributes.
It would be nice to have some comments on these general ideas before
starting to work on them.
/Thomas
next prev parent reply other threads:[~2009-08-03 19:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-03 7:25 [PATCH] x86: Fix CPA memtype reserving in the set_pages_array cases Thomas Hellstrom
2009-08-03 8:11 ` Ingo Molnar
2009-08-03 8:29 ` Dave Airlie
2009-08-03 8:39 ` Thomas Hellstrom
2009-08-03 9:19 ` Ingo Molnar
2009-08-03 10:18 ` Thomas Hellstrom
2009-08-03 10:44 ` Ingo Molnar
2009-08-03 16:58 ` Suresh Siddha
2009-08-03 19:31 ` Thomas Hellström [this message]
2009-08-03 9:18 ` Ingo Molnar
2009-08-03 10:51 ` [tip:x86/urgent] x86: Fix CPA memtype reserving in the set_pages_array*() cases tip-bot for Thomas Hellstrom
2009-08-03 17:39 ` tip-bot for Thomas Hellstrom
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=4A773B26.20007@vmware.com \
--to=thellstrom@vmware.com \
--cc=airlied@linux.ie \
--cc=arjan@infradead.org \
--cc=dri-devel@lists.sourceforge.net \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.com \
/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