public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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




  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