Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5
From: Ingo Molnar (mingo_at_elte.hu)
Date: 08/31/04
- Previous message: Andrew Morton: "2.6.9-rc1-mm2"
- In reply to: Lee Revell: "Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5"
- Next in thread: Lee Revell: "Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5"
- Reply: Lee Revell: "Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 31 Aug 2004 09:06:58 +0200 To: Lee Revell <rlrevell@joe-job.com>
* Lee Revell <rlrevell@joe-job.com> wrote:
> Otherwise, this looks pretty good. Here is a new one, I got this
> starting X:
>
> http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-bk4-Q5#/var/www/2.6.9-rc1-bk4-Q5/trace2.txt
ok, MTRR setting overhead. It is not quite clear to me which precise
code took so much time, could you stick a couple of 'mcount();' lines
into arch/i386/kernel/cpu/mtrr/generic.c's prepare_set() and
generic_set_mtrr() functions? In particular the wbinvd() [cache
invalidation] instructions within prepare_set() look like a possible
source of latency.
(explicit calls to mcount() can be used to break up latency paths
manually - they wont affect the latency itself, they make the resulting
trace more finegrained.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Andrew Morton: "2.6.9-rc1-mm2"
- In reply to: Lee Revell: "Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5"
- Next in thread: Lee Revell: "Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5"
- Reply: Lee Revell: "Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
