From: "Thomas Hellström" <thomas@tungstengraphics.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Dave Airlie <airlied@redhat.com>,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, arjan@linux.intel.com
Subject: Re: [PATCH] x86: create array based interface to change page attribute
Date: Mon, 31 Mar 2008 09:55:20 +0200 [thread overview]
Message-ID: <47F098E8.1050605@tungstengraphics.com> (raw)
In-Reply-To: <87myof8ief.fsf@basil.nowhere.org>
Andi Kleen wrote:
> Dave Airlie <airlied@redhat.com> writes:
>
>>
>> +#define CPA_FLUSHTLB 1
>> +#define CPA_ARRAY 2
>>
>
> I don't think CPA_ARRAY should be a separate case. Rather single
> page flushing should be an array with only a single entry. pageattr
> is already very complex, no need to make add more special cases.
>
>> +
>> + /*
>> + * Only flush present addresses:
>> + */
>> + if (pte && (pte_val(*pte) & _PAGE_PRESENT))
>> + clflush_cache_range((void *) *addr, PAGE_SIZE);
>>
>
> Also it is doubtful clflush really makes sense on a large array. Just
> doing wbinvd might be faster then. Or perhaps better supporting Self-Snoop
> should be revisited, that would at least eliminate it on most Intel
> CPUs.
>
>
I agree that wbinvd() seems to be faster on large arrays on the
processors I've tested. But isn't there a severe latency problem with
that instruction, that makes people really want to avoid it in all
possible cases?
Also I think we need to clarify the semantics of the c_p_a
functionality. Right now both AGP and DRM relies on c_p_a doing an
explicit cache flush. Otherwise the data won't appear on the device side
of the aperture.
If we use self-snoop, the AGP and DRM drivers can't rely on this flush
being performed, and they have to do the flush themselves, and for
non-self-snooping processors, the flush needs to be done twice?
/Thomas
> -Andi
>
next prev parent reply other threads:[~2008-03-31 7:56 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-31 5:19 [PATCH] x86: create array based interface to change page attribute Dave Airlie
2008-03-31 6:54 ` Thomas Hellström
2008-03-31 9:33 ` Arjan van de Ven
2008-03-31 11:04 ` Thomas Hellström
2008-03-31 7:25 ` Andi Kleen
2008-03-31 7:55 ` Thomas Hellström [this message]
2008-03-31 8:38 ` Andi Kleen
2008-03-31 9:06 ` Thomas Hellström
2008-03-31 9:18 ` Andi Kleen
2008-03-31 11:10 ` Thomas Hellström
2008-03-31 16:08 ` Arjan van de Ven
2008-03-31 16:41 ` Thomas Hellström
2008-03-31 16:49 ` Arjan van de Ven
2008-03-31 17:26 ` Thomas Hellström
2008-04-01 20:58 ` Arjan van de Ven
2008-04-01 21:29 ` Thomas Hellström
2008-04-01 22:30 ` Arjan van de Ven
2008-04-02 6:30 ` Thomas Hellström
2008-04-02 6:35 ` Arjan van de Ven
2008-04-02 6:59 ` Thomas Hellström
2008-04-02 14:01 ` Arjan van de Ven
2008-04-02 17:57 ` Thomas Hellström
2008-04-07 18:23 ` Jesse Barnes
2008-04-07 19:51 ` Thomas Hellström
2008-04-07 19:59 ` Jesse Barnes
2008-04-07 20:46 ` Thomas Hellström
2008-04-07 20:57 ` Arjan van de Ven
2008-04-08 6:12 ` Thomas Hellström
2008-04-07 21:04 ` Jesse Barnes
2008-04-08 6:21 ` Thomas Hellström
2008-04-08 14:27 ` Jesse Barnes
2008-04-07 20:56 ` Arjan van de Ven
2008-04-07 21:02 ` Jesse Barnes
2008-04-07 21:09 ` Jesse Barnes
2008-03-31 9:56 ` Arjan van de Ven
2008-03-31 11:21 ` Dave Airlie
2008-03-31 11:46 ` Andi Kleen
2008-04-02 1:35 ` Dave Airlie
2008-04-01 18:20 ` Arjan van de Ven
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=47F098E8.1050605@tungstengraphics.com \
--to=thomas@tungstengraphics.com \
--cc=airlied@redhat.com \
--cc=andi@firstfloor.org \
--cc=arjan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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.